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chapter one 


; f e live in exciting times. The rate at which technology ad- 
vances has grown exponentially over the last century, and even 
more dramatically in the last decade alone. The connecting tissue 
behind this progress may be summarized simply as “more is 
good, faster is better.” This axiom seems equally applied across all 
disciplines, which is a testament to the insatiable nature of our 
being, but the manner in which new advances are applied defines the 
path we take as a society. 

Technology does not exist for its own sake. Rather, each ad- 
vance or evolutionary outgrowth of prior technology must be 
viewed as a tool to change the way we collectively live, work, 
play, and thrive as a society. This is important to grasp from the 
outset because the creation of anew programming standard such 
as Moving Worlds is, at the very heart of things, no different than 
the development process for a hammer. 

First, someone must recognize the need, as in “Gee, it would be a 
lot easier to pound this stake in the ground if I had something 
besides this rock.” Then a process of trial and error ensues until a 
product is designed to fulfill that need. In this case, we are assum- 
ing a sledgehammer. Now—and here is the important point to 
understand—as people use that sledgehammer, they will come up 
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with many more applications of the tool than the original designer 
could have ever imagined on his own. Further, many of those 
applications will result in further refinement of the basic concept to 
the point that entirely new tools arise from it. That is why hardware 
stores now stock dozens upon dozens of types of hammers. 

Within the context of this analogy, you may elect to view UNIX 
as a sledgehammer, a broad powerful tool in the proper hands, 
and Moving Worlds as a tack hammer, an evolutionary product 
designed to meet a very focused, specific need, which is the inte- 
gration of dynamic virtual reality applications on the World Wide 
Web. How that evolution came to take place is the focus of Chap- 
ter 2, “The Evolution of Internet Programming.” In the remainder 
of this chapter, you are given a perspective on the potential signifi- 
cance of Moving Worlds and, I hope, will be excited by the many 
possibilities for exploiting this creative standard. Who knows, you 
might even be the one who devises an application of this language 
that Silicon Graphics, Inc. (SGI) and the other developers haven't 
considered. But first ... 


A Brief History of the World 


The lessons of history are many, but for our purposes a very 
narrow focus will be maintained. In the beginning, all of man’s 
time was consumed completely by the struggle for survival. 
Shelter had to be found near a source of water; plants had to be 
harvested (not cultivated) and game to be hunted. It was a full- 
time job and one of which Darwin would have been proud, for it 
had the added benefit of culling off the weak and infirm. 

Over time, various implements and hand tools eased human- 
kind’s burden somewhat, but it wasn’t until about 200 B.C. that 
things really started looking up. Cato the Elder authored De 
agricultura, the Roman equivalent of Home and Garden, if you will, 
and the use of gears led to the invention of ox-driven water 
wheels for irrigation. The agricultural revolution was born and, 
though its fruits would take many years to spread, the cumulative 
effect was that one person could now feed many people, which 
left a lot of others with time on their hands. 
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Freed from the need to scrabble through the rocks for the barest 
sustenance, the family farm lost some luster in the eyes of most. 
With an abundance of food to be carried or bartered for elsewhere, 
wanderlust sprang up unabated. Such began a period of expan- 
sion, exploitation, colonization, and sheer aggravation (that is, 
war, and lots of it) the likes of which have never been seen before 
or since. The world would never be the same again as it was 
before the agricultural revolution. 

Wars seemed a favorite pastime over the next 2,000 years or so 
because no matter how good you had it, you could always find 
someone else who had it better. The only reasonable thing to do at 
that point was go try to take it away from them, right? Well, that 
was the prevailing train of thought at the time, anyway. 

Then, about 1770, another convergence of events occurred—this 
time in England—that would alter civilization irrevocably again. 
Steam power and textile machines were invented almost simulta- 
neously with the introduction of the broad philosophical concepts 
of international free trade and civil liberties. The industrial revolu- 
tion was spawned and began to spread slowly throughout the 


~ world. 


With mass production a reality, items that were once considered 
luxuries became inexpensive and readily available to most. Also, 
mass production kept a lot of people off the streets and in the 
assembly lines. Piece work is arduous and boring, however; so, as 
you might expect, some elements tired of it quickly despite the 
appealing line of goods in the company store. Lacking the more 
accepted reason for going to war, but loving to go there nonethe- 
less, humankind turned to politics to fuel its favorite pastime. 
Ideological differences were always strong contenders, anyway; 
remember the Crusades? 

Now, the real beauty behind the wars of the nineteenth and, toa 
larger degree, twentieth centuries was that humankind succeeded 
in raising the killing of its fellows to a true art form. It was no 
longer necessary to “wait until you see the whites of their eyes”; 
you could simply sit on the front porch of your silo and frag 
anyone in the world without ever leaving Nebraska. 
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This isn’t about the glorification of war. Remember, weapons 
are tools just like the aforementioned hammer. Remember also the 
basic axiom of “more is better, faster is good.” The point to take 
away about the impact of the wars of the last two centuries is that 
they advanced technology and also were material intensive. 

Even though we could kill each other from a much greater 
distance, we still tended to miss a lot. Thousands of pounds of 
supplies and munitions were attributed to each casualty. Conven- 
tional assembly lines gave way to increased automation to keep 
up with demand. When a war ended and people returned home, 
they found that many of the jobs they had before were being 
performed by machines. Some call this the technological revolu- 
tion, but that downplays the larger societal change that arose from 
it. Most Western civilizations shifted from an industrial economy 
to a service-based economy. 

In a service-based economy, the needs and desires of the indi- 
vidual must be evaluated and managed in much greater detail than 
in a straight, commodity-driven industrial economy. As such, tools 
had to be developed and are continuing to be developed to manage 
that information. Over the last 10 years, information management 
systems have begun to permeate every aspect of our lives. Consider 
a simple trip to the grocery store. Bar coding was introduced as a 
method of simplifying inventory management and restocking for 
retailers. Later, debit card readers were added in every checkout 
lane to speed the payment process. Two seemingly innocuous 
functions of the modern age, two separate bit streams of 
unthreatening data that, when combined, could tell more about a 
family’s habits than some people would care to volunteer. 

This is not to suggest that Moving Worlds is part of some 
conspiracy theory. Rather, Moving Worlds is an information 
management tool that has evolved from other, less capable appli- 
cations before it. Further, the potential applications of Moving 
Worlds are far more powerful than most people comprehend. The 
significance of this cannot be overstated. Humankind is now 
poised on the brink of a third major social revolution, the informa- 
tion revolution, which will dramatically alter civilization once 
again. Moving Worlds has the potential to be one of the first 
catalysts of that change. To understand why, you must also grasp 
the developmental trend toward Virtual Reality. 


Chapter 1: Tomorrow's World, Tomorrow's Web 5) 


Redefining Virtual Reality? 


Virtual reality was defined only once with clarity and vision. This 
occurred in Neal Stephenson’s Snow Crash, which has become 
almost an underground bible among the techno-elite. Since then, 
the concept of virtual reality has been repeatedly diluted by media 
and marketing campaigns whose sole goal was to make worthless 
products appear trendy and cutting edge. I cringe at the possibil- 
ity that any of you gentle readers have developed your sole 
perceptions of VR by donning a Nintendo Virtual Boy. Erase such 
experiences from your mind, for no one has yet developed true 
virtual reality. 

In Stephenson’s world, virtual reality was indistinguishable 
from normal reality, at least in terms of the physical perceptions of 
one’s senses. While riding a virtual bicycle, for example, you 
would feel resistance in your feet (which varied depending on 
how hard you were pedaling), you could feel the wind rushing 
past, hear sounds rise and fall based on proximity and doppler, 
and see the sources of those sounds (such as someone cutting 
grass) by simply looking in the direction that your ears “told” you 
to look. Even the smell of freshly cut grass would be present. And, 
you wouldn’t want to forget to guzzle some tepid water from the 
bike bottle as you sped past. 

Sight, smell, hearing, touch, and taste. Involvement of all the 
primary senses that we rely upon to evaluate our surroundings 
would be necessary for truly immersive virtual reality as 
Stephenson envisioned it. Will Moving Worlds achieve that level 
of interaction? No, but it is the next major advancement toward 
that goal. 

Why? Because reality itself is nothing more than the arrange- 
ment of information in a specific order. Everything exists in three 
dimensions and is acted upon in a fourth dimension, which is 
time. Also, time remains constant in either reality or virtual reality. 
Granted, nothing says that programming cannot accelerate the 
rate of physical processes (such as erosion or decay, for example) 
in a virtual world to something to which we are not accustomed, 
but time itself does not change. Consequently, the first challenge 
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in creating virtual reality was simply to accommodate the arrange- 
ment of geometric shapes so that they would be spatially perceived 
to exist in three dimensions. 

This function was adequately demonstrated, but certainly not 
perfected, by VRML 1.0. The following excerpt from the VRML 1.0 
Specification, authored by Gavin Bell of Silicon Graphics, Inc., and 
Anthony Parisi of Intervista Software, offers insight into the goals 
and mission statement of the designers: 


The Virtual Reality Modeling Language (VRML) is a 
language for describing multi-participant interactive simula- 
tions — virtual worlds networked via the global Internet and 
hyperlinked with the World Wide Web. All aspects of virtual 
world display, interaction and internetworking can be speci- 
fied using VRML. It is the intention of its designers that 
VRML become the standard language for interactive simula- 
tion within the World Wide Web. 

The first version of VRML allows for the creation of virtual 
worlds with limited interactive behavior. These worlds can 
contain objects that have hyperlinks to other worlds, HTML 
documents, or other valid MIME types. When the user selects 
an object with a hyperlink, the appropriate MIME viewer is 
launched. When the user selects a link to a VRML document 
from within a correctly configured WWW browser, a VRML 
viewer is launched. Thus, VRML viewers are the perfect 
companion applications to standard WWW browsers for 
navigating and visualizing the Web. Future versions of VRML 
will allow for richer behaviors, including animations, motion 
physics and real-time multi-user interaction. 
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VRML Mission Statement 


When viewed exclusively as a programming language, VRML 
may be misconstrued as nothing more than an attempt to add 
gloss and visual impact to the Internet. This ignores the larger 
implications of the language, as well as the key motivating factors 
of the original design team. Bell traces these factors in the mission 
statement as follows: 


The history of the development of the Internet has had three 
distinct phases; first, the development of the TCP/IP infra- 
structure which allowed documents and data to be stored in 
a proximally independent way; that is, Internet provided a 
layer of abstraction between data sets and the hosts which 
manipulated them. While this abstraction was useful, it was 
also confusing; without any clear sense of ‘what went 
where,’ access to Internet was restricted to the class of 
sysops/net surfers who could maintain internal cognitive 
maps of the data space. 

Next, Tim Berners-Lee’s work at CERN, where he devel- 
oped the hypermedia system known as World Wide Web, 
added another layer of abstraction to the existing structure. 
This abstraction provided an “addressing” scheme, a unique 
identifier (the Universal Resource Locator), which could tell 
anyone ‘where to go and how to get there” for any piece of 
data within the Web. While useful, it lacked dimensionality; 
there’s no there there within the Web, and the only type of 
navigation permissible (other than surfing) is by direct 
reference. In other words, | can only tell you how to get to 
the VRML Forum home page by saying, “http:// 
www.wired.com/,” which is not human-centered data. In 
fact, | need to make an effort to remember it at all. So, while 
the World Wide Web provides a retrieval mechanism to 
complement the existing storage mechanism, it leaves a lot 
to be desired, particularly for human beings. 
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Finally, we move to “perceptualized” Internetworks, 
where the data has been sensualized, that is, rendered 
sensually. If something is represented sensually, it is pos- 
sible to make sense of it. VRML is an attempt (how success- 
ful, only time and effort will tell) to place humans at the 
center of the Internet, ordering its universe to our whims. In 
order to do that, the most important single element is a 
standard that defines the particularities of perception. Virtual 
Reality Modeling Language is that standard, designed to be 
a universal description language for multi-participant simu- 
lations. 

These three phases, storage, retrieval, and 
perceptualization, are analogous to the human process of 
consciousness, as expressed in terms of semantics and 
cognitive science. Events occur and are recorded (memory); 
inferences are drawn from memory (associations); and from 
sets of related events, maps of the universe are created 
(cognitive perception). What is important to remember is 
that the map is not the territory, and we should avoid be- 
coming trapped in any single representation or world-view. 
Although we need to design to avoid disorientation, we 
should always push the envelope in the kinds of experience 
we can bring into manifestation! 


As you can see, information management is actually at the heart 
of VRML. The designers recognize that experience and retention 
are far greater when information is presented via involvement of 
as many of the senses as possible. VRML is a sensual language. As 
such, it also holds the greatest potential to become a universal 
language. The easier it is for the average nonwired person to 
become part of the Internet community, the more rapidly that 
community will truly become global. 


Chapter 1: Tomorrow's World, Tomorrow's Web 9) 


Creation Through Cooperation and Community 


The Internet is a community, uniquely defined by the techno- 
eccentricities of its inhabitants, perhaps, but a community none- 
theless in every other sense. In this community, more respect is 
gained by having knowledge and willingly sharing it with the 
community than by any other behavior. Long-term Netizens 
(citizens of the Internet) remember a time (prior to the introduc- 
tion of graphical browsers and the World Wide Web) when the 
sheer ability to navigate the Internet was sufficient to convey an 
initial measure of respect to anyone encountered therein. These 
times have changed, and the change itself has been one of the 
most controversial topics on the Internet. 

Some of the old guard techno-elite users resent the influx of 
new, non-savvy Net users entering through commercial services 
such as America Online, CompuServe, Prodigy, and others. This 
resentment is unhealthy, however, and stems from nothing more 
than a feeling of having worked hard to achieve status and then 
watching others be given equivalent access to the same knowl- 
edge base for one-tenth of the effort. A bitter pill to swallow for 
some, perhaps, but far more of the old guard realize that the 
Internet will reach its full potential only through this new blood. 
Mark Pesce, one of the driving forces behind VRML and Moving 
Worlds, belongs to the latter school of thought. 

The debate that defined VRML began as a mailing list main- 
tained at www.Wired.com. The exchange of design concepts, 
analysis, even grandiose free association of ideas, was encouraged 
from the entire Internet community. As such, VRML became the 
first programming language collectively created by the commu- 
nity rather than adopted from a commercial source. The strength 
of that concept alone, that no one entity would actually own the 
principles underlying the source code, was significant. Mark Pesce 
was quoted at the time as saying, “We feel, very strongly, that a 
solution which is proprietary, which is ‘owned’ in any sense by a 
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commercial organization, is unacceptable, and introduces compli- 
cations greater than the task at hand.” The task at hand was great 
enough, however, to require some degree of mediation over the 
free-form design discussion process envisioned. And that is how 
the VAG was born. 


The VRML Architecture Group 

The VRML Architecture Group (VAG) was originally formed to 
create a new standard for 3D Internet programming, based on 
input from the Internet community. Although many organizations 
have representatives on the VAG, the corporate entities are less 
significant than the individuals themselves, each of whom are 
experts in their chosen fields. The goals of the VAG are deter- 
mined by those individuals, and the organization itself was at 
least partially created to provide a means of crossing traditional 
corporate boundaries to find commonality of purpose and work 
for the common good of the Internet and programming communi- 
ties as a whole. The inaugural meeting of the group was held from 
August 20-23, 1995, in Half Moon Bay. The second meeting was 
held October 23-24, in San Francisco. This meeting altered the 
focus of the VAG from actual creation of a standard to providing 
focus to the discussions that would lead to developing a new 
standard. 

The third meeting of the VAG, which was held at Intervista’s 
offices in San Francisco on February 5-6, 1996, finalized a process 
through which proposals for the standard could be evaluated, 
refined, and eventually selected. The VAG members assigned to 
oversee that process were as follows: 


Gavin Bell, gavin@engr.sgi.com 
Brian Blau, blau@intervista.com 
Rikk Carey, rikk@sgi.com 

Jan Hardenbergh, jch@oki.com 

Jon Marbry, jonmarb@microsoft.com 
Tom Meyer, twm@cs.brown.edu 


Tony Parisi, tparisi@intervista.com 
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Mark Pesce, mpesce@netcom.com 
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A call for proposals was put forth to the community, resulting 
in both private and commercial proposals. The move away from 
neutral development by the VAG toward a commercial provider 
did not diminish the community-based nature of the creation 
process, however. Rather, the intent was to cooperatively develop 
the standard design document by soliciting proposals from many 
sources, polling to ascertain the community’s reaction to each 
proposal, and then synthesizing the best elements to come up with 
a finalized design document. Should the selected standard come 
from a commercial provider, then development of that standard 
would also be accelerated by the larger resource pool associated 
with such a provider. 


How Moving Worlds Fits Into the Process 

Moving Worlds is a developmental concept proposal initiated by 
Silicon Graphics, Inc., in conjunction with Sony and World Makers. 
The proposal was authored in response to a call for proposals from 
the VAG. The Moving Worlds proposal was one of six submitted 
proposals for a new standard to update the Virtual Reality Model- 
ing Language (VRML) from version 1.x to version 2.0. The other 
proposals in contention, and the institutions that submitted them, 
are as follows: 


S The Power of Dynamic Worlds, German National Research 
Center for Information Technology, Institute for Applied 
Information Technology 


Holoweb, Sun Microsystems 
Out of This World, Apple 
ActiveVRML, Microsoft 


Reactive Virtual Environment, IBM Japan 
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Each of the proposals had considerable merit, and, naturally, 
almost all of them overlapped in accomplishing the broad objec- 
tives outlined by the VAG. The devil is in the details, however, 
and the differences in execution between the various proposals 
generated extensive debate within the VRML community. In the 
course of defending their respective positions, some of the discus- 
sion threads became a bit passionate but, in the end, the demo- 
cratic process employed by the VAG prevailed. 
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The polling results follow: 


| 


. How would you rate your interest in the ActiveVRML pro- 


posal? (181 votes counted) 
Strongly in Favor: 14 (8%) 
Moderately in Favor: 32 (18%) 
Neutral: 27 (15%) 

Moderately Against: 43 (24%) 
Strongly Against: 65 (36%) 


. How would you rate your interest in the Dynamic Worlds 


proposal? (116 votes counted) 
Strongly in Favor: 12 (10%) 
Moderately in Favor: 30 (26%) 
Neutral: 46 (40%) 

Moderately Against: 17 (15%) 
Strongly Against: 11 (9%) 


. How would you rate your interest in the HoloWeb proposal? 


(128 votes counted) 

Strongly in Favor: 6 (5%) 
Moderately in Favor: 30 (23%) 
Neutral: 48 (38%) 

Moderately Against: 27 (21%) 
Strongly Against: 17 (13%) 


. How would you rate your interest in the Moving Worlds 


proposal? (191 votes counted) 
Strongly in Favor: 130 (68%) 
Moderately in Favor: 45 (24%) 
Neutral: 7 (4%) 

Moderately Against: 6 (3%) 
Strongly Against: 3 (2%) 


. How would you rate your interest in the Out of this World 


proposal? (139 votes counted) 
Strongly in Favor: 15 (11%) 
Moderately in Favor: 18 (13%) 
Neutral: 41 (29%) 

Moderately Against: 33 (24%) 
Strongly Against: 32 (23%) 
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6. How would you rate your interest in the Reactive Virtual 
Environment proposal? (44 votes counted) 
Strongly in Favor: 1 (2%) 
Moderately in Favor: 1 (2%) 
Neutral: 10 (23%) 
Moderately Against: 15 (34%) 
Strongly Against: 17 (39%) 
7. In which proposal are you most strongly in favor? (186 votes 
counted) 
ActiveVRML: 18 (10%) 
Dynamic Worlds: 11 (6%) 
HoloWeb: 5 (3%) 
Moving Worlds: 138 (74%) 
Out of This World: 14 (8%) 
Reactive Virtual Environment: 0 (0%) 


With the overwhelming support for SGI’s Moving Worlds 
proposal, the VAG began the rather onerous task of integrating the 
best of the proposed revisions and additions to that proposal to 
place it in final form. The resulting document is presented in its 
entirety in Chapters 3 through 6, Appendix A, Appendix B, and 
parts of Chapters 2 and 7. Continuing the theme of this chapter, 
however, I now examine some of the big-picture elements of the 
Moving Worlds proposal, and then close with additional perspec- 
tive on the potential impact and implications of the new standard. 


The Broad Objectives of Moving Worlds 


As with the refinement process of any tool, many of the proposed 
changes to VRML 1.x were direct reflections of user feedback on 
the original product, which allowed refinement of some broad 
themes to pursue in subsequent development. Though not specifi- 
cally called out in the proposal as such, the unifying objectives of 
the new standard may be summarized as follows: 


WS To improve interactivity by adding behaviors to objects that 
may be expressed over time. 
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Ww To maximize the use of shared properties and behaviors to 
keep individual scene size small and minimize download 
times. 


To improve accessibility by simplifying code requirements, 
thereby promoting a broader penetration into the user base 
than was achieved by VRML 1.x. 


To maintain good downward compatibility with applica- 
tions created under prior versions of VRML. 


To provide users of worlds created under VRML 2.0 with 
the most sensual experience attainable, free from the re- 
strictions of local area networks, and platform independent 
for the entire global community. 


The methods by which Moving Worlds achieves these objectives 
are examined in Chapters 3 through 7. Although the achievements 
themselves are exciting, the implications of the new standard are 
even more compelling. I will touch on some of those now, then 
expand on them in Chapter 8, “Designing Moving Worlds.” 


Overcoming Inertia 


& 


= 


Inertia is a fundamental law of physics that states that, in the 
absence of external forces, bodies at rest tend to remain at rest and 
bodies in motion tend to remain in motion. The same may be said 
of societies and the status quo. After things have been a certain way 
for a long time, it takes a significant force to get them moving again. 
As little as five years ago, almost no one outside the educational 
community, the government, and some segments of the corporate 
world knew much about the Internet. Now it is impossible to take a 
five-minute drive in a city, watch an hour of television, or walk 
through a mall without being inundated by URL addresses. Devel- 
opment of a graphical interface for the Internet via the World Wide 
Web has certainly increased awareness, but many potential users 
are still daunted by the technical aspects of the medium. Granted, it 
is fear based on ignorance alone, but it still must be overcome to see 
the Internet become the first true global medium. 

The world is quite comfortable with other visual media, and the 
tremendous communicative advantage of images over text is 
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indisputable. Further, the power of video tape or film over still 
photography is that action over time is conveyed. Now, place a 
person inside that environment and let him or her influence the 
action that occurs over time, and you begin to understand why 
Moving Worlds represents the first true opportunity to overcome 
the inertia associated with technophobia. 


Power of Presentation 


Proceeding under the premise that the new standard will be 
compelling enough to attract a true mass audience, let’s examine 
the potential of the language from the perspective of a designer 
with a message to convey to that audience. Consider for a moment 
what an automobile manufacturer might do with the power 
offered by Moving Worlds. 

Why not start with a 3D representation of the vehicle, imbed- 
ded with certain behaviors when you click on hot spots? Clicking 
on the roof of a convertible, for example, might put the top down. 
Clicking on the hood might raise it to let you look at how acces- 
sible various engine components are. Naturally, of course, you 
would have to have control of a floating camera to change per- 
spective as well. 

Enough of that, now it’s time to take a test drive. Hop in and 
take your potential purchase for a drive on the autobahn, around 
the track at Indianapolis, even across the Baja if you want. In this 
instance, immersion would not be as critical as maintaining 
perspective, because driving is basically a sedentary activity 
anyway. The designers could provide whatever environments 
they thought best demonstrated the car’s performance and, as 
long as they could prove that their computer performance models 
were in keeping with actual performance under similar condi- 
tions, what an incredible sales tool their Web site could become. 

Note: Remember, it is all about information management, and 
Moving Worlds offers tremendous ability to present information 
spatially over time and directly involve the user in the manipula- 
tion of that information. 


16 Exploring Moving Worlds 


3D Education 


Getting students excited about history can be difficult, but how 
much easier would it be to teach medieval history, for example, if 
students could walk around the inside of a feudal lord’s manor, or 
man the battlements against an enemy siege, or even pick up and 
examine the goods at the local market. 

What about biology? Do you want to understand what it’s like 
to be a predator? Why not step inside a lion’s skin and hunt the 
Serengeti. The Discovery Channel recently produced a stand-alone 
multimedia product that used a similar approach, but consider the 
greater impact of multiple users in a classroom setting working 
cooperatively to stalk a herd of antelope. How much greater is the 
insight gained by working through a problem or situation with 
others, using as many senses as possible within the constraints of 
the medium and having the missing senses replaced through 
other means (for example, “you feel the wind on the left side of 
your face and it carries the scent of prey”)? Studies have proven 
conclusively time and again that the greater the degree of 
interactivity, the higher the retention of the student. As such, the 
potential of educational applications built on the Moving Worlds 
standard is staggering. 


Research Potential 


What if you needed to determine how most human beings would 
react under a specific set of circumstances in a specific environ- 
ment? Why not create those conditions virtually and allow users 
of this virtual world to be willing test subjects? Catalog user 
interaction with and reaction to the artificial circumstances, and 
you have just completed a very cost-effective research project. 
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Interactive Entertainment 


Of all the potential applications of the new standard, the one that 
likely will be most recognizable to readers is that of interactive 
entertainment. Modem- and network-capable games have become 
a mainstay of the entertainment software industry. The reasons 
behind this trend are easy to understand. 

First and foremost, despite years of artificial intelligence re- 
search and development, finding a good computer opponent long 
term is like searching for the Holy Grail. Nothing compares to the 
intuitive nature of man, or his unpredictability in a challenging 
situation. For example, even the best AI routines for enemy pilots 
in a flight simulation must still follow some pattern of probability 
and, sooner or later, players figure that pattern out. Try putting 30 
human-controlled aircraft aloft at the same time in a simulation 
such as Kesmai’s Air Warrior, however, and try to find a pattern in 
those dogfights. 

Second, multiplayer games are becoming the norm again 
because social interaction is at the very root of gaming itself. In 
fact, with the exception of Solitaire and its variations, almost all 
gaming had the human element at its core until the computer age. 
Solitaire computer gaming became the de facto standard because 
technology didn’t allow real-time interaction between multiple 
players at that time. Needless to say, technology has changed and 
gaming is returning to its roots. In five years or fewer, there won’t 
be a single piece of entertainment software released that doesn’t 
include the ability to play with others via the Internet. Moving 
Worlds will be a major factor in creating the new arenas in which 
we can play. 
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The Power of Information 


The real power of a good information management system is that 
it not only allows information to be presented in many different 
ways, but also allows users of the system to customize it to fit their 
needs. Moving Worlds will become a new standard for Internet 
programming but users will customize their search for informa- 
tion on a VRML-dominant World Wide Web through applications 
known as browsers. Whereas Netscape has effectively captured 
the HTML browser market via its Navigator 2.0 package, expect a 
good deal of competition before a similar successor is defined for 
the VRML 2.0 market. At this point, who that successor will be is 
less important to understand than what such a browser will offer. 

On a truly 3D Web, users will have the freedom to arrange the 
locations /scenes in that universe in whatever fashion suits their 
tastes. When you go to the mall, do you spend all your time in the 
bookstore and the video outlet? Why bother with all the rest of it, 
then? Simply crawl the Web and find all of the Moving Worlds- 
compatible sites offering those items and arrange the sites inside 
your own architecture. Browse the mall of your dreams and even 
invite a few friends with similar tastes to come shopping with 
you. Carry on a conversation with them in real time and watch the 
expression on their avatar’s face change as their mood does. 

Does any of the above sound more like science fiction than 
something you expect to see tomorrow? If so, then it’s time to 
really catch up. Remember the following themes as you move 
through the book: 


S Moving Worlds is an information management tool. It is a 
refinement of VRML, which has evolved from user feed- 
back on the earlier product. 


© Tools are important, but the manner in which they are 
applied defines our progress as a society. 


Most of the Western World is in a service-based economy 
that has stemmed from the technological revolution. 


“s The most important tool sets in service-based economies 
are information-management tools. 
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The Internet is a community, and all communities benefit 
from the diversity and individuality of their inhabitants. 


WS The greater the ease with which a community may be 
joined, the broader and more diverse its membership will 
become. 


Moving On 


Visionaries may see the road ahead, beyond that next hill, but 
pioneers must actually climb that hill and map the road for those 
who follow. By virtue of purchasing this book, you have already 
proven yourself a pioneer, an early adopter of what the future 
promises. Use this work to help you find the way into that future, 
and then, when you get there, build something interesting and 
invite the rest of the world to come and see it. Very few frontiers 
remain to be explored in the physical world, but the horizons of 
cyberspace stretch out indefinitely, limited only by the imagina- 
tions of explorers. Congratulations on taking the first step toward 
tomorrow. 

The upcoming chapter is designed to take you yet another step 
closer to your goal by adhering to the old maxim, “to know where 
you are going, you must first understand where you have been.” 
The Internet is a dynamic, growing animal, capable of speaking in 
many tongues or languages. To appreciate the design of Moving 
Worlds, you must trace its roots, both in terms of the infrastruc- 
ture of the Internet itself and, more importantly, the programming 
languages and protocols used to manage information. Once that 
has been accomplished, we will begin exploration of the Moving 
Worlds specification itself. 
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chapter two 


(i days, when the word Internet inevitably arises in a con- 
versation, the discussion usually focuses on video streaming, Java 
applets, and other multimedia gloss. Such topics, although perhaps 
adequately detailing the current technological trends, do little to 
actually address the question: “What is the Internet?” Comparing 
the modern information superhighway Internet of today with its 
prehistoric, almost unknown counterpart of 10 years ago, one 
might well believe that Netscape Communications Corporation, 
America Online, and Microsoft Corporation have redesigned the 
Internet, supplanting an obsolete system with a modern, more 
streamlined version of itself. Despite technological innovations by 
these (and many other) entities, today’s Information Revolution 
has more to do with how users incorporate the Internet into their 
daily routine than actual changes to the Internet itself. 


How the Internet Works 


What, then, is the Internet? In simplest terms, the Internet can best 
be visualized as a collection of wires. Whether it’s fiber-optic cable 
or copper wire, the Internet itself is nothing more than a weblike 
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mesh stretched among computer systems worldwide. Although 
more computers are entwined in this labyrinth now than a decade 
prior, and enhanced modem technology has substantially im- 
proved access to the maze, the Net itself has endured little change. 
If you view the global computer network as a living entity, the 
individual computers represent individual organs: the heart, liver, 
and lungs of this behemoth. The Internet forms the creature’s 
circulatory system, using its web of copper veins and fiber-optic 
arteries to carry the beast’s blood: data. 

Clearly, though, this is not your father’s Internet. If the network 
itself has changed little over the last decade, how then is today’s 
Internet so much more functional? It boils down to two aspects: 
size and protocol. 


he defense industry first established ARPANET in the 
Js, only a few computers were attached to the network. By 
., the number had grown to 1,000 and, by 1987, to 10,000. 
fo years later, in 1989, the number increased to 100,000. By 
1992, the number again increased by an order of magnitude to 
i break the 1 million mark and reportedly topped the 2 million 

~ mark in 1993. | 


First, the increased size has had a profound impact on the 
visible face of the Internet. The Internet was originally a utilitarian 
creation, a product developed by engineers for engineers. Engi- 
neers are comfortable with obscure acronyms and elaborate 
command lines resembling more a random assortment of letters 
than an intelligible command. Accordingly, engineers typically 
delight in creating and implementing complex protocols but 
loathe devoting even one unnecessary millisecond to tailoring the 
user interface. The huge size increase means that many more users 
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have Internet access today. Many of the old school consider the 
late 1980s as a Golden Age of the Internet. Even though it didn’t 
have the current menu of features and functionality, being on the 
Internet was something special; the average person couldn’t get 
there. Today, anyone with a 9600 baud modem can get access to 
the Internet, and the online population surge has created demand 
for new products and features as well as significantly changing 
the overall personality of the Net community. The Net is no longer 
an elite country club for engineers and scholars, and the horde of 
new users has demanded a less cryptic interface. 

Second, protocol is basically a set of rules. Most activities in life 
have some governing protocol complete with penalties for disobe- 
dience. Protocol governing a formal dinner dictates silverware 
usage and may spawn a social scandal should one of the guests 
inadvertently use the dinner fork while eating the salad. Poker 
protocol enumerates very specific rules and behavior, a violation 
of which can result in severe bodily injury. Likewise, transactions 
over the Internet are governed by a complex and ever-improving 
set of protocols. As users, we rarely see the underlying hardware 
network and usually consider the visible software applications as 
“the Internet.” 

Internet protocols come in several varieties. Layered upon each 
other, each protocol depends on a lower level to support it. Like 
the layers of a wedding cake, the plastic bride and groom depend 
on the topmost level for support. The topmost level, however, 
rests on a larger level directly below it. That level, in turn, rests on 
another, and another, and so on until you finally reach the table. 
The Internet can be viewed as dozens of wedding cakes sitting on 
the same table. The plastic couple (which represents the user) on 
top of one cake communicates to the other plastic couples on the 
other wedding cakes by sending messages down through each 
layer of cake. Imagine each message as a marble dropped into the 
cake that sinks to the very bottom. As the marble passes through 
each layer of cake, some crumbs and icing stick to the marble, 
altering its course and appearance. In similar manner, each layer 
of protocol alters and manipulates the individual messages before 
passing them to the next protocol layer. The marbles eventually 
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sink to the table, roll into another cake, and are then passed 
upward though the second cake until they reach the recipient 
plastic bride and groom. 

Likening the Internet to a wedding cake, each layer of protocol 
corresponds to a layer of the cake. At the bottom, the lowermost 
level represents the hardware network: the computers of the 
Internet and the wires strung between them. As explained previ- 
ously, except for getting larger, the hardware level has changed 
very little. With this layer of the cake in place, we have a medium 
for transmitting messages between computers. We have no rules 
governing those messages, however, or how to send them. This 
layer of protocol will just as readily accept binary garbage as 
coherent messages. Even if a message is introduced to the net- 
work, who knows where it will end up? 

Climbing, we find the next level of the “cake” to be a different 
flavor. This level is the Internet Protocol, or IP layer. Without the 
hardware level beneath it, the IP layer could not exist. The IP layer 
dictates a method for getting messages from point a to point b. 
Each host machine connected to the Internet has a unique IP 
address, a “phone number,” if you will. The IP address looks 
something like “205.105.199.21” and identifies a specific computer 
in the network exactly as a telephone number identifies a specific 
house within a city. With the IP layer of the cake in place, we now 
have a system for properly routing messages to the right recipient. 
We still have no rules about what those messages should look like, 
and the message will be unintelligible to the recipient. 

So, we climb to a higher level of the cake to the Transport Control 
Protocol, or TCP layer. When we decide to send a string of binary 
numbers from one IP address to another, we encounter a new 
problem. We want to route from computer a, through b, and 
deliver our message to computer c. Meanwhile, someone else is 
trying to send a message from computer a through b to computer 
d. Both messages try to use the a-b link at the same time, causing 
system contention. 

The TCP layer resolves this conflict. It divides messages up into 
smaller sections called packets. Continuing to liken messages to 
marbles, when a marble falls down into the TCP layer, the TCP 
cracks it into tiny little pieces, then drops each fragment, or 
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packet, down through the IP layer to the hardware layer. The 
packets are shipped through the network, taking any route they 
can to arrive at their destination. Along the way, the original 
grouping of sequential packets invariably encounters another 
string of packets heading the same way. The individual packets 
fall out of order and become mixed up, but thanks to another 
aspect of the TCP layer, each packet knows its destination and 
continues toward the ordered destination. The TCP layer also 
gives each packet a sequence number. When packets arrive out of 
order, the TCP layer in the recipient cake reassembles them in the 
correct sequence. In effect, the recipient TCP layer reassembles 
each marble from the broken pieces. Packets then reassemble 
themselves in the correct sequence. Thanks to the TCP and IP 
layers (commonly called a TCP/IP connection), we can now send a 
message over the network from point a to point b without worry- 
ing about traffic jams. Still, though, we have not specified any 
rules about what those messages should look like. When the 
recipient gets the message, will it say, “Hello, how are you doing 
today?” or will it say “Ghhfff4%%2?” Based on the protocols 

we’ ve discussed so far, there’s no way to know. 

Thus we come to the top layer of the cake, the application proto- 
col. The plastic bride and groom, representing the computer users, 
stand on top of this level. All tools and utilities, from Telnet to FTP 
to Web browsing, are part of the application protocol. This is the 
visible face of the Internet. From their vantage point, the plastic 
bride and groom cannot “see” the TCP layer, the IP layer, or the 
hardware layer. Yet, if any of these layers suddenly disappeared, 
the application layer (and the bride and groom standing on it) 
would come tumbling down. 

Each host computer on the network is a separate “cake.” After 
the layers are all in place, the system is ready for the plastic bride 
and groom. The bride enters a command, perhaps an e-mail 
message. The command goes to the application layer. The applica- 
tion creates the appropriate network messages and specifies the 
recipient’s IP address. The application letter then sends the mes- 
sage down to the TCP layer. The TCP layer divides the message 
into individually addressed and sequenced packets, and then 
sends the packets down to the IP layer. The IP layer sends the 
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packets through the hardware layer. Each IP layer in each com- 
puter on the network is constantly watching the hardware layer 
for messages addressed to that computer. When the recipient’s 
host computer sees the IP address on the packets from our ex- 
ample e-mail message, the IP layer effectively grabs the packets 
from the hardware layer and passes them up to the TCP layer. The 
TCP layer collects all the packets, reassembles them in order, and 
hands them up to the application layer. The application layer 
formats the message and displays it on the screen where the 
plastic groom can read it. 

The primary changes to the Internet over the past decade have 
mostly been to the visible, application layer. Initially, the plastic 
wedding couple stood on an odd-shaped slab of dry, yellow cake. 
Within a few years, they stood on a circular piece of yellow cake. 
In the modern Internet, the plastic pair now stands on a fresh, 
perfectly round layer of chocolate cake with raspberry filling and 
topped with a thick coat of icing. 

Now let’s examine the changes in the application layer over the 
years. The nature of the Internet, especially of the UNIX operating 
system, gives engineers on the host machines considerable access 
to the TCP layer. Individual application protocols specify methods 
of transporting mail, logging in to remote systems, and cruising 
the Web. Programmers then write applications to pass information 
from the user to the application protocol. A mail program, for 
example, uses a different application protocol than a Web browser. 

Essentially, engineers can write user applications at will. Typi- 
cally, when anyone authored a specific application for a specific 
task, another programmer would immediately author an alterna- 
tive application for the same task. As a result, the application layer 
has been filled with evolutionary dead ends; that is, programs that 
failed to catch on and eventually fell by the wayside. Arguably, 
some of these extinct creatures may have been better applications 
than their surviving cousins, but suffered the fate of the dinosaurs 
nonetheless. Given the wide variety of applications and applica- 
tion protocols, any list that endeavors to document the history of 
the Internet, including this one, will invariably omit a few signifi- 
cant entries. Such omissions in no way diminish the contributions 
of the omitted party to the evolution of the Internet. 
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e Internet 

rce of the Internet can be traced to the Soviets launching 
yutnik satellite in 1957. Although the Cold War politics of 
space race tactics can be argued ad infinitum, one thing is 
r: the United States was determined to win. As a result, the 
oO. Department of Defense formed the Advanced Research 
Projects dee Its ce. establish a U.S. technological lead in 
military. During the 1960s, engineers look- 
ing fora communications network capable of surviving a nuclear 
war pursued a unique concept. During an attack, parts of the net- 
work would always be vulnerable. Switching equipment, cables, 
and so on could never be completely shielded. Because there 
was no way to build a network that could be assumed reliable at 
all times, engineers switched gears and designed a network as- 
sumed to be unreliable at all times! The network would be built 
like a web with multiple routes to every destination. Packet-switch- 
ing technology arose in the late 1960s, and by the 1970s, the 
15-node ARPANET was born. Tracing the history of networking 
and interconnectivity, we see that today’s Internet is a direct de- 
scendant of this Cold War program. The Internet is, therefore, yet 
another entry in the long list of benefits to the civilian commu- 
nity originally developed by the military. 


E-mail 


A computer network linking researchers around the world would 
be of little use if those researchers couldn’t communicate with 
each other. Electronic mail (e-mail), or sending written letters over 
a computer network, is one of the Internet’s primary application 
protocols. Most of us can’t afford to travel to one hundred differ- 
ent countries every week, or daily call thousands of people world- 
wide on the telephone. Using e-mail, however, Net users can 
communicate with thousands of people in hundreds of countries 
around the world every day. 
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As with most application protocols, e-mail requires a server 
program. The server program runs on the host computer as part of 
the top level of the cake. It watches messages coming up from the 
TCP layer and grabs those labeled as e-mail. It analyzes who the 
message is to, and then stores the message in that user’s mailbox. 
On most UNIX systems, the $MAIL variable points to the user’s 
raw datafile. Users rarely access their mail that way, though. 
Instead, they run various application programs that read and 
format the raw mailbox. 

The e-mail protocol has changed little in recent years. Applica- 
tion programs, though, have improved tremendously, advancing 
from the minimalist mail on UNIX systems to the GUI-based 
Eudora mail reader. The relative stagnation of the protocol, how- 
ever, introduces other problems. E-mail protocol uses a 7-bit 
environment, meaning that each binary word contains only seven 
digits. This makes e-mail rather unsuitable for transmitting 8-bit 
files, such as program executables, without add-on packages such 
as UUENCODE, MIME, and BINHEX. 


Get Wired 

ote of interest, Queen Elizabeth of the United Kingdom 
edly joined the information age sometime in the 1970s, 
ng an e-mail message of her own. All available evidence 
icates that this message was sent in 1976, although persistent 
rumors place the transmission date anywhere from 1971 to 1978. 


UUCP 


In 1976, AT&T Bell Labs engineers developed UUCP, or UNIX to 
UNIX cp (cp is the UNIX command for copying files from one 
place to another). Using roughly a dozen subprotocols, the VUUCP 
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protocol provided network users with a viable, common method 
for transmitting files across the network. Within one year, UUCP 
was a standard tool shipped with the UNIX operating system. 
UUCP provides a list of utilities and commands, such as “uucp,” 
“uuto,” and others. 


Usenet and Newsgroups 


In 1979, UUCP directly spawned one of the Internet’s most well- 
known features: Usenet. Using UUCFP to transfer files between 
machines, Usenet is a global conferencing system composed of 
discussion areas called newsgroups. Using a variety of news- 
reading application programs, users effectively can post messages 
on the world’s largest bulletin board system. As the hardware 
network has grown and improved, so has the Usenet network. 

Functionally, Usenet newsgroups gave people around the world 
a virtual “conference room” in which to hold group discussions. 
Socially, however, Usenet created something far more critical: a 
sense of online community. Participating in a newsgroup discus- 
sion carries a larger sense of human interactivity than e-mail. The 
open nature of newsgroups (that is, anybody with access can post 
any message that he or she wants) led to the development of 
Netiquette, or the etiquette of Usenet posters. Netiquette is, in 
essence, a user-built application protocol residing on top of the 
Usenet application. Netiquette is a complex social ritual, filled 
with tradition and myths. Failing to comform to Netiquette can 
have dire consequences to your online social life! 

Conforming to Netiquette (or attempting to punish those who 
do not conform) created a sense of community in the online 
world. Although the Usenet interface is fairly limited in scope, the 
online community that it created is to the modern Internet com- 
munity what primitive villages are to modern cities. Just as an- 
cient humans came to gather in small villages along rivers and in 
fertile valleys, and ultimately developed these villages into towns 
and eventually cities, ancient Internet users began settling along 
fertile areas of the electronic frontier and established the basis of 
online community. 
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Today, Usenet has grown beyond its UUCP roots. UUCP is still 
a prime part of Usenet, but other protocols such as Net News 
Transfer Protocol, or NNTP (introduced in 1986), have appeared. 
Usenet has grown into a massive system that few can even define, 
let alone explain. 


TCP/IP 


As explained previously, the TCP and IP protocol layers effec- 
tively control how messages travel from point a to point b. These 
protocols went through several phases until 1982, when TCP/IP 
was formally adopted as the ARPANET protocol. This was one of 
the first times that interconnected networks were officially re- 
ferred to as “Internet.” 


Domain Name System 


In 1984, the Domain Name System (DNS) revolutionized the 
“Internet phone book,” if you will, and established the now- 
common domain system of .com, .edu, .org., and .gov. Prior to this 
time, systems communicated using IP addresses such as 
128.9.0.32. The DNS provided for a translation between a host 
computer’s name and its IP address. For example, users could 
now connect to something like compuserve.com rather than 
149.174.214.132. 


WAIS 


WAIS, or Wide Area Information Search, first surfaced in 1991. 
WAIS is effectively a server-based, searchable, information data- 
base. Using keywords, users can search a WAIS server for any 
information on that particular topic stored on that server. Al- 
though WAIS is an effective tool, the advent of the Web seems to 
have sent it to an early grave. 
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Gopher came out of the ground in 1991. Although it doesn’t have 
the graphical capability of the World Wide Web, it does depart 
from the standard command line interface. Gopher provides a 
menu-based information indexing system. Users connecting to a 
Gopher server find items available from that system displayed 
onscreen as a list. | 


The World Wide Web (HTTP, HTML, and CGI) 


The Web is best viewed as a collection of related application proto- 
cols. Arguably, the introduction of the HyperText Transfer Protocol 
(HTTP), which allows users to send documents using HyperText 
Markup Language (HTML), is the single biggest revolution to hit 
the Internet. Released in 1991, this application protocol is the basis 
of the World Wide Web (WWW), which many people now equate 
with the Internet itself. Host machines run a server program, such 
as httpd, which provides the application protocol. The user’s 
application programs, such as Netscape Navigator and Mosaic, 
communicate with the server program to transmit and receive 
HTML code. The application program then formats the display 
accordingly and shows it to the user. Both HTTP and HTML can be 
considered application protocols. HTTP specifies how you send 
HTML documents over the network, whereas HTML specifies what 
kinds of commands those documents can include. The HTML 
language is constantly growing and evolving, adding new com- 
mands and increasing functionality. Application programs are 
improving also. Current Web browsers, such as Netscape Naviga- 
tor, understand more than the HTTP protocol. Navigator also 
understands Usenet newsgroups, FTP, and e-mail protocols, as well 
as supporting WAIS and Gopher, allowing you to perform all of 
these functions in addition to Web browsing. 

The Common Gateway Interface (CGI) links websmiths, the 
users who actually write Web pages, back to the operating system. 
HTML code primarily defines only how a page should look on the 
screen. It does not provide any executable commands. Using the 
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CGI system, websmiths can execute a variety of officially sup- 
ported and user-built scripts. This functionality lets users count 
how many times their page has been accessed, process form input 
data, and much more. 

HTML and the resultant World Wide Web transformed the 
Internet from an acronym-filled, command-line environment 
designed for the technically proficient to an acronym-filled, GUI 
environment designed for the average person. Initially, HTML 
supported sounds and graphics, letting users create aesthetically 
pleasing Web pages. Further, HTML lets users interact with 
graphics and sounds. Before the Web, users looking for informa- 
tion on llamas might have typed: 

ftp 205,125.222.22 

anonymous 

thunk@bog.edu 

cd/pub/animals/I/llamas 

ascii 

get Il_dec_text.tar 


Now, with the Web, the same user can likely find the same 
information by simply clicking on a picture of a llama. Depending 
on what part of the llama the user clicks, he or she can get differ- 
ent information. With the appropriate user applications installed 
on their computers, users can watch movies about llamas, listen to 
llamas, and even talk in real-time with other llama fans (or to the 
actual llamas themselves, for that matter). Although finding a 
coherent path through the Web can be a difficult process, search 
engines such as Lycos and Open Text greatly improve the users’ 
ability to locate information on the Web. 


Java 


CGI scripts offer a powerful link from the Web browser to the host 
machine. Unfortunately, for security concerns, most Web servers 
do not let individual users access or write CGI utilities. If a 
websmith needs a particular CGI tool, he or she must convince the 
server administrator to provide it. On some servers, getting the 
administrator to provide additional tools in a timely manner is 
more difficult than having teeth pulled. 
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Netscape, always at the forefront of Web technology, now offers 
users a way around the CGI bottleneck: Java. Java, developed by 
Sun Microsystems, Inc., is effectively a “watered down” version of 
the C programming language. It is compiled and stored on the 
Web server, then accessed and executed by the Web browser. Java 
has proven itself as a powerful tool, letting websmiths craft all 
sorts of animated and interactive Web applications. 

As of this writing, only the 32-bit version of Netscape Navigator 
(for Windows 95 or similar 32-bit operating systems) supports Java. 


VRML 


When a user browses the Web by following a link, the browser 
application in use (be it Netscape Navigator, Mosaic, or whatever) 
analyzes the type of information contained in the linked file. 
HTML, text, and images are displayed directly as dictated by the 
file script received. To retrieve other types of information, such as 
audio or video files, the browser must pass the request to another 
application, commonly referred to as a plug-in application. First- 
generation VRML browsers are plug-in applications. Common 
VRML browsers include WebSpace, WebView, WebFX, Whirlwind, 
and Live 3-D. 

VRML links call up geometric shapes, the attributes of which are 
defined in a larger VRML environment. These shapes might include 
doors that users can click on to “walk though” and enter a new 
environment, windows to look at other environments, or objects 
within an environment that link to retrieve other VRML documents. 

The greatest limitations of the original VRML language were 
that it was essentially static, and also that it failed to achieve the 
level of user penetration necessary to really become a universal Net 
standard. In the remaining sections of this chapter (excluding 
“Moving On”), SGI presents its conception of how Moving Worlds 
is positioned to rectify the shortcomings of earlier VRML imple- 
mentations. 
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What Moving Worlds Is All About 


VRML 1.0 provided a means of creating and viewing static 3D 
worlds; VRML 2.0 will provide much more. The overarching goal 
of the Moving Worlds proposal for VRML 2.0 is to provide a 
richer, more exciting, more interactive user experience than is 
possible within the static boundaries of VRML 1.0. The secondary 
goals of the proposal are to provide a solid foundation that future 
VRML expansion can grow out of, and to keep things as simple 
and as fast as possible—for everyone from browser developers 
to world designers to end users—given the other goals. 

Moving Worlds provides these extensions and enhancements 
to VRML 1.0: 


ws Enhanced static worlds 
Ww Interaction 
w Animation 


WS Prototyping 


Enhanced Static Worlds 


You can add realism to the static geometry of your world using 
new features of Moving Worlds: 


ws New nodes allow you to create ground-and-sky backdrops 
to scenes, add distant mountains and clouds, and dim 
distant objects with fog. Another new node lets you easily 
create irregular terrain instead of using flat planes for 
ground surfaces. 


Wy 


Moving Worlds provides sound-generating nodes to fur- 
ther enhance realism—you can put crickets, breaking glass, 
ringing telephones, or any other sound into a scene. 


YW 


If you’re writing a browser, you'll be happy to see that 
optimizing and parsing files are easier than in VRML 1.0, 
thanks to a new simplified scene graph structure. 
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Interaction 


No more moving like a ghost through cold, dead worlds; now you 
can directly interact with objects and creatures that you encounter. 
New sensor nodes set off events when you move in certain areas 
of a world and when you click certain objects. They even let you 
drag objects or controls from one place to another. Another kind of 
sensor keeps track of the passage of time, providing a basis for 
everything from alarm clocks to repetitive animations. 

And, no more walking through walls. Collision detection 
ensures that solid objects react like solid objects; you bounce off 
them (or simply stop moving) when you run into them. Terrain 
following allows you to travel up and down steps or ramps. 


Animation 


Moving Worlds wouldn’t be able to move without the new Script 
nodes. Using Scripts, you not only can animate creatures and 
objects in a world but also give them a semblance of intelligence. 
Animated dogs can fetch newspapers or Frisbees; clock hands can 
move; birds can fly; robots can juggle. 

These effects are achieved by means of events; a script takes 
input from sensors and generates events based on that input, 
which can change other nodes in the world. Events are passed 
around among nodes by way of special statements called Routes. 


Prototyping 


Have an idea for a new kind of geometry node that you want 
everyone to be able to use? Got a nifty script that you want to turn 
into part of the next version of VRML? In Moving Worlds, you can 
encapsulate a group of nodes together as a new node type, a 
prototype, and then make that node type available to anyone who 
wants to use it. You can then create instances of the new type, each 
with different field values—for instance, you can create a Robot 
prototype with a robotColor field, and then create as many indi- 
vidual different-colored Robot nodes as you like. 
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Example of Prototyping: Gone Fishing 
So, how does all this fit together? Here’s a look at possibilities for 
implementing a fully interactive demo world called Gone Fishing. 

In Gone Fishing, you start out hanging in space near a floating 
worldlet. If you wanted a more earthbound starting situation, you 
could (for instance) make the worldlet an island in the sea, using a 
Background node to show shaded water and sky meeting at the 
horizon as well as distant unmoving geometry like mountains. 
You could also add a haze in the distance using the fog parameters 
in a Fog node. 

As you approach the little world, you can see two neon signs 
blinking on and off to attract you to a building. Each of those signs 
consists of two pieces of geometry under a Switch node. A 
TimeSensor generates time events which a Script node picks up 
and processes; the Script then sends other events to the Switch 
node telling it which of its children should be active. All events are 
sent from node to node by way of Route statements. 

As you approach the building—a domed aquarium on a raised 
platform—you notice that the entry portals are closed. There 
appears to be no way in, until you click the front portal; then it 
immediately slides open with a motion like a camera’s iris. That 
portal is attached to a ClickSensor that detects your click; the 
sensor tells a Script node that you've clicked, and the Script 
animates the opening portal, moving the geometry for each piece 
of the portal a certain amount at a time. The script writer had only 
to specify certain key frames of the animation; interpolator nodes 
generate intermediate values to provide smooth animation be- 
tween the key frames. The door, by the way, is set up for collision 
detection using a Collision node, so that without clicking to open 
it you'd never be able to get in. 

You enter the aquarium and a light turns on. A BoxProxim- 
itySensor node inside the room noticed you coming in and sent an 
event to, yes, another Script node, which told the light to turn on. 
The sensor, script, and light can also easily be set up to darken the 
room when you leave. 
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Inside the aquarium, you can see and hear bubbles drifting up 
from the floor. The bubbles are moved by another Script; the 
bubbling sound is created by a PointSound node. As you move 
further into the building and closer to the bubbles, the bubbling 
sound gets louder. 

Besides the bubbles, which always move predictably upward, 
three fish swim through the space inside the building. The fish 
could all be based on a single Fish node type, defined in this file 
by a PROTO statement as a collection of geometry, appearance, 
and behavior; to create new kinds of fish, the world builder could 
just plug in new geometry or behavior. 

Proximity sensors aren’t just for turning lights on and off; they 
can be used by moving creatures as well. For example, the fish 
could be programmed (using a similar BoxProximitySensor / 
Script /ROUTE combination to the one described above) to avoid 
you by swimming away whenever you got too close. Even that 
behavior wouldn’t save them from users who don’t follow direc- 
tions, though. 

Despite (or maybe because of) the warning sign on the wall, 
most users “touch” one or more of the swimming fish by clicking 
them. Each fish behaves differently when touched; one of them 
swims for the door, one goes belly-up. These behaviors are yet 
again controlled by Script nodes. 

To further expand Gone Fishing, a world designer might allow 
users to “pick up” the fish and move them from place to place. 
This could be accomplished with a PlaneSensor node, which 
translates a user’s click-and-drag motion into translations within 
the scene. Other additions—sharks that eat fish, tunnels for the 
fish to swim through, a kitchen to cook fish dinners in, and so 
on—are limited only by the designer’s imagination. 

Gone Fishing is just one example of the sort of rich, interactive 
world you can build with Moving Worlds. For details of the new 
nodes and file structure, see the conceptual section of the Moving 
Worlds proposed specification (printed in Chapter 3 of this book, 
“Key Concepts of Moving Worlds.”) 
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Moving On 


So, what have you learned so far? 

First and foremost, you have learned that Moving Worlds is a 
powerful tool for the creation of interactive, 3D virtual environ- 
ments (realities, if you prefer) on the World Wide Web. You’ve also 
learned that these environments will be populated by animate and 
inanimate objects, spatially placed sounds, reactive and interactive 
behaviors, and, of course, the users themselves. Each user will 
have a counterpart inside the environment commonly referred to 
as an Avatar. Avatars will be able to see and converse with one 
another, work together to manipulate the environments they 
share, or even compete against one another for resources within 
that environment. Gee, sounds like real life, doesn’t it? 

Because of all of these factors, programmers can create applica- 
tions that more closely approximate either their real-world coun- 
terparts, such as a virtual real estate tour of a neighboring city, or 
more properly convey the intended setting of fantasy environ- 
ments, such as riding across Arrakis on the back of a great sand 
Wyrm from Frank Herbert’s science fiction classic Dune. 

Because these environments are more familiar and easier to 
interact with than earlier forms of information presentation on the 
Internet, they will be more compelling to new users as well. 
Moving Worlds is therefore a potential catalyst to the establish- 
ment of a truly wired world, a global Internet community whose 
inhabitants will interact with one another in ways that once were 
only within the purview of science fiction. 

Finally, and of greatest importance, the interactivity promised 
as integral to Moving Worlds will allow those same users to define 
the map of this new community, ordering the information within 
it to their whim. At the simplest level, that might entail a VRML 
2.0 browser search that retrieves only information on Polynesian 
architecture and sculpture, after which the user assembles the 
objects collected from all over the global Internet into a single 
Moving Worlds environment to explore. 
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Such a creation could exist solely for one’s own research or 
enjoyment, or be given back to the community as a whole. Based 
on experience, the latter outcome will be the most prevalent. Users 
will apply this tool to arrange information in ways that they find 
compelling or exciting, and then offer it to others who may, in 
turn, add their own personal touch. In other words, with Moving 
Worlds, the collective community of the Internet can not only 
grow and thrive in an environment that is simultaneously familiar 
and compelling, but also shape that environment to suit the tastes 
of individuals and groups alike. Few mediums, information 
management tools, or applications are capable of serving a broad 
base of users concurrent with providing the power of narrow 
focus for those who desire it. Moving Worlds is just such a tool. 
Now let’s begin to see how Moving Worlds makes this magic a 
reality, virtual or not. 
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chapter three 


Ths section describes key concepts related to the defini- 
tion and use of VRML, including how nodes are combined 
into scene graphs, how nodes receive and generate events, 
how to create node types using prototypes, how to add 
node types to VRML and export them for use by others, and 
how to incorporate programmatic scripts into a VRML file. 
Key Concepts includes the following sections: 


File Syntax and Structure 

ww URLs and URNs 

File Extension and MIME Types 
Nodes, Fields, and Events 


 % 


The Structure of the Scene Graph 
 Instancing 

Coordinate Systems and Transformations 
Viewing Model 


w Time 
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Events 
Routes 
Sensors 
WS Prototypes 
W Defining Prototypes in External Files 
Extensibility 


Naming Conventions for Prototypes 


Y 


Scripting 

Script Languages 
Ww Execution Model 
Ww Browser Interface 


This document’s URL: http: / /webspace.sgi.com/ 
moving-worlds/spec/concepts.html. 


File Syntax and Structure 


For easy identification of VRML files, every VRML 2.0 file must 
begin with the characters: 


#VRML V2.0 utf8 


The identifier utf8 allows for international characters to be 
displayed in VRML using the UTF-8 encoding of the ISO 10646 
standard. Unicode is an alternate encoding of ISO 10646. UTF-8 is 
explained under the Text node (see “Text” in Chapter 3 of this book). 

Any characters after these on the same line are ignored. The line 
is terminated by either the ASCII newline or carriage-return 
characters. 

The # character begins a comment; all characters until the next 
newline or carriage return are ignored. The only exception to this 
is within double-quoted SFString and MFString fields, where the 
# character will be part of the string. 

Note: Comments and whitespace may not be preserved; in 
particular, a VRML document server may strip comments and 
extra whitespace from a VRML file before transmitting it. 
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WorldInfo nodes should be used for persistent information such 
as copyrights or author information. To extend the set of existing 
nodes in VRML 2.0, use prototypes or external prototypes rather 
than named information nodes. 

Blanks, tabs, newlines and carriage returns are whitespace 
characters wherever they appear outside of string fields. One or 
more whitespace characters separate the syntactical entities in 
VRML files, where necessary. 

After the required header, a VRML file can contain the following: 


Any number of prototypes defined using PROTO or 
EXTERNPROTO. 


ww Any number of nodes. 
© Any number of ROUTE statements. 


See the Syntax Reference section (in Chapter 6 of this book) for 
more details. | 

Field, event, prototype, and node names must not begin with a 
digit (0x30-0x39) but may otherwise contain any characters except 
for non-printable ASCII characters (0x0-0x20), double or single 
quotes (0x22, 0x27: “’), sharp (0x23: #), comma (0x2c: ,), period 
(Ox2e: .), square brackets (Ox5b, 0x5d: []), backslash (Ox5c: \) or 
curly braces (Ox7b, 0x7d: {}). Characters in names are as specified 
in ISO 10646, and are encoded using UTF-8. 

VRML is case-sensitive; “Sphere” is different from “sphere” and 
“BEGIN” is different from “begin.” 


URLs and URNs 


A URL (Universal Resource Locator) specifies a file located on a 
particular server and accessed through a specified protocol. A 
URN (Universal Resource Name) provides a more persistent way 
to refer to data than is provided by a URL. The exact definition of 
a URN is currently under debate. See the discussion at http:// 
www.w3.org/hypertext/ WWW / Addressing / Addressing. html 
for further details. 
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All fields in VRML 2.0 that have URLs are of type MFString. 
The strings in such a field indicate multiple places to look for files, 
in decreasing order of preference. If the browser can’t locate the 
first file or doesn’t know how to deal with the URL or URN given 
as the first file, it can try the second location, and so on. 

VRML 2.0 browsers are not required to support URNs. If they 
do not support URNs, they should ignore any URNs that appear 
in MFString fields along with URLs. URN support is specified in a 
separate document at http://earth.path.net/mitra/papers/ 
vrml-urn.html, which may undergo minor revisions to keep it in 
line with parallel work happening at the IETF. 

Relative URLs are handled as described in IETF RFC 1808, 
“Relative Uniform Resource Locators.” 


File Extension 


The file extension for VMRL files is .wrl (for world). 


MIME Type 


The MIME type for VRML files is defined as follows: 
x-world/x-vrml 


The MIME major type for 3D world descriptions is x-world. The 
MIME minor type for VRML documents is x-vrml. Other 3D 
world descriptions, such as oogl for The Geometry Center’s 
Object-Oriented Geometry Language, or iv, for SGI’s Open Inven- 
tor ASCII format, can be supported by using different MIME 
minor types. 

It is anticipated that the official type will change to “model/ 
vrml”. At this time, servers should present files as being of type 
x-world/x-vrml. Browsers should recognise both x-world/x-vrml 
and model/vrml. 

IETF work-in-progress on this subject can be found in “The 
Model Primary Content Type for Multipurpose Internet Mail 
Extensions.” 
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Nodes, Fields, and Events 


At the highest level of abstraction, VRML is just a file format for 
describing objects. Theoretically, the objects can contain any- 
thing—3D geometry, MIDI data, JPEG images, and so on. VRML 
defines a set of objects useful for doing 3D graphics. These objects 
are called nodes. Nodes contain data, which is stored in fields. 

VRML defines several different classes of nodes. Most of the 
nodes can be classified into one of two categories; grouping nodes 
or leaf nodes. Grouping nodes gather other nodes together, allow- 
ing collections of nodes (specified in a grouping-node field called 
children) to be treated as a single object. Some grouping nodes also 
control which of their children are drawn. 

Leaf nodes may not have children. Nodes that are considered 
leaf nodes include shapes, lights, viewpoints, sounds, scripts, 
sensors, interpolators, and nodes that provide information to the 
browser. 

Shape nodes contain two kinds of additional information: 
geometry and appearance. For purposes of discussion, this specifi- 
cation uses a third node category, subsidiary nodes, for nodes that 
are always used within fields of other nodes and cannot be used 
alone. These nodes include geometry (for example, Cone and 
Cube), geometric property (for example, Coordinate3 and Nor- 
mal), appearance (Appearance) and appearance property nodes 
(for example, Material and Texture2). 


General Node Characteristics 


oe 


A node has the following characteristics: 


A type name. This is a name like Cube, Sphere, 
DirectedSound, SpotLight, and so on. The parameters 
distinguish this node from other nodes of the same type. 
For example, each Sphere node might have a different 
radius, and different spotlights have different intensities, 
colors, and locations. These parameters are called fields. A 
node can have 0 or more fields. Each node type defines the 
type, name, and default value for each of its fields. The 
default value for the field is used if a value for the field is 
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\S 


not specified in the VRML file. The order in which the 
fields of a node are read is not important; for example, 
“Cube {width 2 height 4 depth 6}” and “Cube {height 4 
depth 6 width 2}” are equivalent. 


A set of associated events it can receive and send. Most 
nodes can receive a number of set_ events (such as 
set_position, set_color, and set_on), which change the node. 
Most nodes can also send a number of _changed events, 
which indicate that something in the node has changed (for 
example, position_changed, color_changed, on_changed). 
In the node description, events a node can receive are 
labeled eventIn. The exposedField keyword can be used as 
a short-hand way of specifying that a given field has both a 
set_ eventIn and _changed eventOut associated with it. For 
example, the declaration: 


exposedField foo 


is equivalent to the declaration: 


field foo 
eventIn set_foo 
eventOut foo_changed 


The syntax for representing these pieces of information is as 
follows: 


nodetype { fields } 


Only the node type and braces are required; nodes may or 
may not have fields. 


Sample File Format 


For example, this file contains a simple scene defining a view of a 
red cone and a blue sphere, lit by a directional light: 


#VRML V2.0 utf8 
Transform { 


children [ 


DirectionalLight { 
direction 0 0 -1 # Light shining into scene 
i. 
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Transform { # The red sphere 
translation 3 0 1 
children [ 
Shape { 


geometry Sphere {radius 2.3} 
appearance Appearance [ 
material Material {diffuseColor 1 0 0} ] # Red 
} 
] 
ie 


Transform { # The blue cube 
translation -2.4 .2 1 
rotation WA 8 
children [ 
Shape { 
geometry Cube {} 
appearance Appearance [ 
material Material {diffuseColor 0 0 1} J] # Blue 


The Structure of the Scene Graph 


This section describes the general scene graph hierarchy, how to 
reuse nodes within a file, coordinate systems and transformations 
in VRML files, and the general model for viewing and interaction 
within a VRML world. 


Grouping Nodes and Leaves 


A scene graph consists of grouping nodes and leaf nodes. Group- 
ing nodes, such as Transform, LOD, and Switch, can have child 
nodes. These children can be other grouping nodes or leaf nodes, 
such as shapes, browser information nodes, lights, cameras, and 
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sounds. Appearance, appearance properties, geometry, and geo- 
metric properties are contained within Shape nodes. 

Transformations are stored within Transform nodes. Each 
Transform node defines a coordinate space for its children. This 
coordinate space is relative to the parent (Transform) node’s 
coordinate space—that is, transformation accumulates down the 
scene graph hierarchy. 


Instancing 


A node may be referenced in a VRML file multiple times. This is 
called instancing (using the same instance of a node multiple 
times; called aliasing or multiple references by other systems) and is 
accomplished by using the DEF and USE keywords. 

The DEF keyword gives a node a name and creates an instance 
of the node. The USE keyword indicates that a previously named 
node should be used again. If several nodes were given the same 
name, then the last DEF encountered during parsing “wins.” 
DEF/USE is limited to a single file; EXTERNPROTO/PROTO 
must be used to refer to a node type that is defined in another file. 
For example, if a node is defined inside a file referenced by a 
WWWihline node, the file containing the WWWInline node 
cannot USE that node. 

Rendering the following scene results in three spheres being 
drawn. Both of the spheres are named “Joe”; the second (smaller) 
sphere is drawn twice, on either side of the first (larger) sphere: 

#VRML V2.0 utf8 

Transform { 

children [ 
DEF Joe Sphere { }, 
Transform { 
translation 2 0 0 
children [ 
DEF Joe Sphere { radius .2 } 
] 
I, 
Transform { 
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translation -2 0 0 
children [ 
USE Joe # radius .2 sphere will be used here; most 

recent one defined 

] 

} 
] 

} 


Tools that create VRML files may need to modify the user- 
defined node names to ensure that a multiply instanced node with 
the same name as some other node will be read correctly. The 
recommended way of doing this is to append an underscore 
followed by an integer to the user-defined name. Such tools 
should automatically remove these automatically generated 
suffixes when VRML files are read back into the tool (leaving only 
the user-defined names). 

Similarly, if an un-named node is multiply instanced, tools will 
have to automatically generate a name to correctly write the 
VRML file. The recommended form for such names is just an 
underscore followed by an integer. 


Coordinate Systems and Transformations 


VRML uses a Cartesian, right-handed, 3-dimensional coordinate 
system. By default, objects are projected onto a 2-dimensional 
display device by projecting them in the direction of the positive Z 
axis, with the positive X axis to the right and the positive Y axis 
up. A modeling transformation can be used to alter this default 
projection. 

The standard unit for lengths and distances is meters. The 
standard unit for angles is radians. 

VRML scenes may contain an arbitrary number of local (or 
object-space) coordinate systems, defined by the transformation 
fields of the Transform node. These fields are translation, rotation, 
scale, scaleOrientation, and center. 
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Given a vertex V and a series of transformations such as: 


Transform { 
translation T 
rotation R 


scale 5 
children [ 
Shape { 
geometryL PointSet { ... }] 
} 
] 


} 


the vertex is transformed into vertex V’ in world-space by first 
scaling, then rotating, and finally translating. In matrix-transfor- 
mation notation, thinking of T, R, and S as the equivalent transfor- 
mation matrices, 


Vio = T#R*S#V 
(if you think of vertices as column vectors) or 
Vio = VeS*R*T 


(if you think of vertices as row vectors). 

Conceptually, VRML also has a world coordinate system. The 
various local coordinate transformations map objects into the 
world coordinate system, which is where the scene is assembled. 
Transformations accumulate downward through the scene graph 
hierarchy, with each Transform inheriting the transformations of 
its parents. (Note however, that this series of transformations 
takes effect from the leaf nodes up through the hierarchy. The 
local transformations closest to the Shape object take effect first, 
followed in turn by each successive transformation upward in 
the hierarchy.) 


Viewing Model 


This specification assumes that there is a user viewing and inter- 
acting with the VRML world. It is expected that a future extension 
to this specification will provide mechanisms for creating multi- 
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participant worlds. The viewing and interaction model that 
should be used for the single-participant case is described here. 

The world creator may place any number of viewpoints in the 
world—interesting places from which the user might wish to view 
the world. Each viewpoint is described by a Viewpoint node. 
Viewpoints exist in a particular coordinate system, and either the 
viewpoint or the coordinate system may be animated. 

It is expected that browsers will support user-interface mecha- 
nisms by which users may “teleport” themselves from one view- 
point to another, and scripting-language mechanisms by which a 
viewer can be bound to a viewpoint which can then be animated. 
If a user teleports to a viewpoint that is moving (one of its parent 
coordinate systems is being animated), then the user should move 
along with that viewpoint. 

The browser may provide a user interface that allows the user 
to change his or her viewing position or orientation, which will 
also change the currently bound viewpoint. 


Time 


The browser controls the passage of time in a world by causing 
TimeSensors to generate events as time passes. Specialized brows- 
ers or authoring applications may cause time to pass more quickly 
or slowly than in the real world, but typically the times generated 
by TimeSensors will roughly correspond to “real” time. 

A world’s creator must make no assumptions about how often a 
TimeSensor will generate events but can safely assume that each 
time event generated will be greater than any previous time event. 

Typically, a TimeSensor affecting a visible (or otherwise percep- 
tible) portion of the world will generate events once per “frame,” 
where a “frame” is a single rendering of the world or one time- 
step in a simulation. 
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Events 


Most nodes can receive events, which have names and types 
corresponding to their fields, with the effect that the correspond- 
ing field is changed to the value of the event received. For ex- 
ample, the Transform node can receive set_translation events (of 
type SFVec3f) that change the Transform’s translation field (it may 
also receive set_rotation events, set_scale events, and so on). 

Nodes can also generate events that have names and types 
corresponding to their fields when those fields are changed. For 
example, the Transform node generates a translation_changed 
event when its translation field changes. 


Routes 


The connection between the node generating the event and the 
node receiving the event is called a route. Anode that produces 
events of a given type can be routed to a node that receives events 
of the same type using the following syntax: 


ROUTE NodeName.eventOutName_changed 10 
NodeName. set_eventInName 


The prefix set_ and the suffix _changed are conventions, not 
rules. However, exposedFields implicitly define set_ eventIn and 
_changed eventOut for a given exposed Field. 

Routes are not nodes; ROUTE is merely a syntactic construct for 
establishing event paths between nodes. ROUTE statements may 
appear at either the top-level of a .wrl file or prototype implemen- 
tation, or may appear inside a node wherever fields may appear. 

The types of the eventIn and the eventOut must match exactly; 
for example, it is illegal to route from an SFFloat to an SFInt32 or 
from an SFFloat to an MFFloat. 

Routes may be established only from eventOuts to eventIns. 
Since exposedFields implicitly define a field, an eventIn, and an 
eventOut for a given field, it is legal to use the exposed Field’s 
defined name when routing to and from it, (rather than specifying 
the set_ prefix and _changed suffix). For example, the following 


Chapter 3: Key Concepts of Moving Worlds 53 


ClickSensor’s enabled exposedField is routed to the 
DirectionalLight’s on exposed field. Note that all four routing 
examples below are legal syntax: 


DEF CLICKER ClickSensor { enabled TRUE } 
DEF LIGHT DirectionalLight { on FALSE } 


ROUTE CLICKER.enabled TO LIGHT.on 


or 
ROUTE CLICKER.enabled_changed TO LIGHT.on 
or 
ROUTE CLICKER.enabled TO LIGHT.set_on 
or 


ROUTE CLICKER.enabled TO LIGHT.set_on 

Given two exposedFields of a node “field1” and “field2”, the 
following is illegal: 

ROUTE node.fieldl TO node.field2 # ILLEGAL 

Instead the corresponding eventIns/eventOuts must be used: 


ROUTE node.fieldl_changed TO node.set_field2 # OR: 
ROUTE node.field2_changed TO node.set_fieldl 


Sensors 


Sensor nodes generate events. Geometric sensor nodes 
(BoxProximitySensor, ClickSensor, CylinderSensor, DiskSensor, 
PlaneSensor, and SphereSensor) generate events based on user 
actions, such as a mouse click or navigating close to a particular 
object. TimeSensor nodes generate events at regular intervals, as 
time passes. 
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Prototypes 


Prototyping is a mechanism that allows the set of node types to be 
extended from within a VRML file. It allows the encapsulation 
and parameterization of geometry, behaviors, or both. 

A prototype definition consists of the following: 


the PROTO keyword. 
the name of the new node type. 
a list of events the new node type can send and receive. 


a list of fields that the new node type makes publicly 
accessible, with default values. 


the definition of the new node type. This definition is a 
scene graph composed of existing nodes and uses the IS 


keyword to substitute the new field and event names for 
the built-in names. 


Square brackets enclose the list of events and fields, and braces 
enclose the definition itself: 


PROTO prototypename [ eventIn eventtypename name 
eventOut eventtypename name 
exposedField fieldtypename name 

defaultValue 
field fieldtypename name 

defaultValue 
rape 


Scene graph 


(nodes, prototypes, and routes, containing IS statements) 
} 


A prototype is not a node; it merely defines a prototype (named 
prototypename) that can be instantiated later in the same file as if 
it were a built-in node. The implementation of the prototype is 
contained in the scene graph rooted by node. That node may be 
followed by Script and/or ROUTE declarations, as necessary to 
implement the prototype. 
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PROTO and EXTERNPROTO statements may appear anywhere 
ROUTE statements may appear—at either the top-level of a .wrl 
file or prototype implementation, or inside a node wherever fields 
may appear. 

The eventIn and eventOut declarations export events from the 
scene graph rooted by node. Specifying the type of each event in 
the prototype is intended to prevent errors when the implementa- 
tion of prototypes is changed and to provide consistency with 
external prototypes. 

Events generated or received by nodes in the prototype’s 
implementation are associated with the prototype using the 
keyword IS. For example, the following statement exposes a 
Transform node’s built-in set_translation event by giving it a new 
name (set_position) in the prototype interface: 

PROTO FooTransform [ eventIn SFVec3f set_position ] { 

Transform { set_translation IS set_position } 


} 


Fields hold the persistent state of VRML objects. Allowing a 
prototype to export fields allows the initial state of a prototyped 
object to be specified when an instance of the prototype is created. 
The fields of the prototype are associated with fields in the imple- 
mentation using the IS keyword. For example: 


PROTO BarTransform [ exposedField SFVec3f position ] { 
Transform { translation IS position } 


} 


IS statements may appear inside nodes wherever fields may 
appear. Specifying an IS statement for a node that is not part of a 
prototype’s implementation is an error. It is an error for an IS 
statement to refer to something that is not part of the prototype’s 
interface declaration. It is an error if the type of the field or event 
being exposed does not match the type declared in the prototype’s 
interface declaration. 

A prototype is instantiated as if typename were a built-in node. 
For example, a simple chair with variable colors for the leg and 
seat might be prototyped as: 
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PROTO TwoColorChair [ field MFColor legColor .8 .4 .7 
field MFColor seatColor .6 .6 .1 ] { 
Transform { 
children [ 


Transform { # chair seat 
children [ 
Shape { 
appearance Appearance { 
material Material { diffuseColor IS seatColor } 
} 
geometry Cube { ... } 
} 
] 
bs 


Transform { # chair leg 
translation ... 
children [ 
Shape { 
appearance Appearance { 
material Material { diffuseColor IS legColor } 
} 
geometry Cylinder { ... } 
} 
] 
} 


] # End of root Transform's children 
| # End of root Transform 
} # End of prototype 


The prototype is now defined. Although it contains a number of 
nodes, only the legColor and seatColor fields are public. Instead of 
using the default legColor and seatColor, this instance of the chair 
has red legs and a green seat: 

TwoColorChair { 

legColor 1 0 0 
seatColor 0 1 0 
} 
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Prototype instances may be named using DEF and may be 
multiply instanced using USE. 
A prototype instance can be used in the scene graph wherever 
its root node can be used. For example, a prototype defined as: 
PROTO MyObject [ ... ] { 
Transform {a2} 


} 


can be instantiated wherever a Transform can be used, since the 
root node of this prototype’s implementation is a Transform node. 

A prototype’s implementation defines a DEF/USE name scope 
separate from the rest of the scene; nodes DEF’ed inside the proto- 
type implementation may not be USE’ed outside of the prototype 
implementation, and nodes DEF’ed outside the prototype imple- 
mentation may not be USE’ed inside the prototype implementation. 

Prototype definitions appearing inside a prototype implementa- 
tion are local to the enclosing prototype. For example, given the 
following: 


PROTO one [ J { 
PROTO two [ J] { ... } 


two { } #Instantiation inside "one": OK 
} 


two { } # ERROR: "two" may only be instantiated inside "one". 


The second instantiation of “two” is illegal. IS statements inside 
such a nested prototype’s implementation may not refer to the 
enclosing prototype’s interface. 

A prototype may be instantiated in a file anywhere after the 
completion of the prototype definition. A prototype may not be 
instantiated inside its own implementation (i.e., recursive proto- 
types are illegal). The following example produces an error: 

PROTO Foo [] { 

Foo {} 

} 
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Defining Prototypes in External Files 


The syntax for defining prototypes in external files is as follows: 


EXTERNPROTO prototypename [ eventIn eventtypename name 
eventOut eventtypename name 
field fieldtypename 

nee, od 

“ORE or TL "URE "URE" f-a54 J 


The external prototype is then given the name prototypename 
in this file’s scope. It is an error if the eventIn/eventOut declara- 
tion in the EXTERNPROTO is not a subset of the eventIn/ 
eventOut declarations specified in the PROTO referred to by the 
URL. If multiple URLs are specified, the first one found should be 
used. 

Unlike a prototype, an external prototype does not contain an 
inline implementation of the node type. Instead, the prototype 
implementation is fetched from a URL or URN. The other differ- 
ence between a prototype and an external prototype is that external 
prototypes do not contain default values for fields. The external 
prototype points to a file that contains the prototype implementa- 
tion, and this file contains the default values. 

To allow the creation of libraries of small, re-usable PROTO 
definitions, browsers should recognize EXTERNPROTO URLs 
that end with “#name” to mean the prototype definition of 
“name” in the given file. For example, a library of standard mate- 
rials might be stored in a file called “materials.wrl” that looks like: 

#VRML V2.0 utf8 

PROTO Gold [] { Material { ... appropriate fields ... } } 


PROTO Silver [] { Material { ... } } 
etc. 


A material from this library could be used as follows: 


#VRML V2.0 utf8 
EXTERNPROTO Gold [] "http://.../materials.wrl#Gold" 


Shape { appearance Appearance { material Gold {}} 
geometry ... 


} 
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The advantage is that only one http fetch needs to be done if 
several things are used from the library; the disadvantage is that 
the entire library will be transmitted across the network even if 
only one thing is used from it. 


Extensibility 


prototypes or external prototypes. External prototypes provide a 
way to extend VRML in a manner that all browsers will under- 
stand. If a new node type is defined as an external prototype, 
other browsers can parse it and understand what it looks like, or 
they can ignore it. An external prototype uses the URL syntax to 
refer to an internal or built-in implementation of a node. For 
example, suppose your system has a Torus geometry node. This 
node can be exported to other systems using an external proto- 
type: 

EXTERNPROTO Torus [ field SFFloat bigRadius 

field SFFloat smallRadius ] 
["urn:yourdomain:Torus", "http://machine/directory/protofile" ] 


The browser can recognize the URN and look for its own 
internal implementation of the Torus node. If it does not recognize 
the URN, it goes to the next URL and searches for the specified 
prototype file. In this case, if the file is not found, it ignores the 
Torus. If more URLs are listed, the browser tries each one until it 
succeeds in locating an implementation for the node or it reaches 
the end of the list. 


Naming Conventions for Prototypes 


Check the “File Syntax and Structure” section of this standard 

(earlier in this chapter) for the rules on valid characters in names. 
To avoid namespace collisions with nodes defined by other 

people, any of the following conventions should be followed: 
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1. Anyone can pick names that include a suffix of an underscore 
followed by a domain name that you own with the periods 
changed into underscores. For example, a company owning 
foo.com could create an extension node “Cube_foo_com”. 

2. If you are building a product—for example, an authoring tool 
or a browser—or defining a lot of new nodes, then you can 
apply for a short prefix. Email type_registry@vrmL.org to 
register for the prefix. This will normally be accepted if it is the 
most significant part of a .com, .org, or .net address. In the 
above example, foo.com could register the extension “_ foo” 
and create nodes of the form “Cube_foo”. 

3. Extensions supported by several companies should be regis- 
tered and use the “_X” extension. 


Scripting 


Logic is often necessary to decide what effect an event should 
have on the scene—"if the vault is currently closed AND the 
correct combination is entered, THEN open the vault.” These 
kinds of decisions are expressed as Script nodes that take in 
events, process them, and generate other events. A Script node can 
also keep track of information between invocations, “remember- 
ing” what its internal state is over time. 

The event processing is done by a program contained in (or 
referenced by) the Script node’s behavior field. This program can be 
written in any programming language that the browser supports. 

A Script node is activated when it receives an event. At that 
point the browser executes the program in the Script node’s 
behavior field (passing the program to an external interpreter if 
necessary). The program can perform a wide variety of actions: 
sending out events (and thereby changing the scene), performing 
calculations, communicating with servers elsewhere on the 
Internet, and so on. 

Two of the most common uses for scripts will probably be 
animation (using interpolators to smoothly move objects from one 
position to another) and network operations (connecting to serv- 
ers to allow multi-user interaction). 
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Script Languages 


Scripts can be written in a variety of languages, including Java, C, 
and Perl. Moving Worlds does not require browsers to support 
any particular language. See appendices to this specification for 
bindings to Java and C (Appendix A and Appendix B in this book, 
respectively). 


Execution Model 


Every time a Script node receives one or more eventin’s, they are 
delivered to the associated script as a queue of events. In its 
simplest implementation the script consists of one function or 
method for each eventIn in the Script node. For each eventIn in 
the queue, the appropriate method is executed, ordered by the 
time of receipt of the eventIn. These methods are passed the data 
from the eventIn and an SFTime of its time stamp, both of which 
are const parameters. 

The author can also define an eventsProcessed( ) method, 
executed after all eventIn methods are called, to perform any post- 
processing necessary. For instance, the eventIn methods can 
simply collect data, allowing eventsProcessed( ) to process all the 
data at once, preventing duplication of work. 

Actual event processing is handled by the processEvents( ) 
method or function. This is passed an array of event structures, 
each containing the name of the eventIn, its data, and the time 
stamp when it was received. A default implementation of this 
method is provided with the functionality described in the previ- 
ous paragraphs. This may be overridden, however, giving the 
author complete control over event processing. 

After all events in the queue are handled, either on return from 
eventsProcessed( ) or processEvents( ), values stored during script 
execution as eventOuts are sent, one for each eventOut that was 
set at least once during script execution. At most one message is 
sent for each eventOut value. 
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In languages that allow multiple threads, such as Java, you can 
use the standard language mechanisms to start new threads. 
When the browser disposes of the Script node (as, for instance, 
when the current world is unloaded), the script’s shutdown( ) 
method will be called to allow the script to gracefully terminate 
any threads it may have created. 

If you want to keep static data in a script (that is, to retain 
values from one invocation of the script to the next), you can use 
instance variables—local variables within the script, declared 
private. However, the value of such variables can’t be relied on if 
the script is unloaded from the browser’s memory; to guarantee 
that values will be retained, they must be kept in fields of the 
Script node. 


Nodes and Fields 


The API provides a data type in the scripting language for every 
field type in VRML. For instance, the Java bindings contain a class 
called SFFloat, which defines methods for getting and setting the 
value of variables of type SFFloat. A script can get and set the 
value of its own fields using these data types and methods. 

The API also provides a way to access other nodes in the scene. 
It allows getting the value of any exposed field of any node that 
the Script has access to. 


Browser Interface 


The API provides ways for scripts to get and set global informa- 
tion associated with the VRML browser, such as the URL of the 
current world. Here are descriptions of the functions /methods 
that the browser API supports. The syntax given is the Java syntax. 


public static String getName(); 
public static String getVersion(); 


The getName() and getVersion() methods get the “name” and 
“version” of the browser currently in use. These values are de- 
fined by the browser writer, and identify the browser in some 
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(unspecified) way. They are not guaranteed to be unique or to 
adhere to any particular format, and are for information only. If 
the information is unavailable these methods return empty 
strings. 

public static float getCurrentSpeed(); 


The getCurrentSpeed() method returns the speed at which the 
viewpoint is currently moving, in meters per second. If speed of 
motion is not meaningful in the current navigation type, or if the 
speed cannot be determined for some other reason, 0.0 is returned. 


public static float getCurrentFrameRate( ); 


The getCurrentFrameRate() method returns the current frame 
rate in frames per second. The way in which this is measured and 
whether or not it is supported at all is browser dependent. If 
frame rate is not supported, or can’t be determined, 100.0 is 
returned. 


public static String getWor1ldURL(); 
public static void loadWorld(String [] ur1); 


The getWorldURL() method returns the URL for the root of the 
currently loaded world. loadWorld() loads one of the URLs in the 
passed string and replaces the current scene root with the VRML 
file loaded. The browser first attempts to load the first URL in the 
list; if that fails, it tries the next one, and so on until a valid URL is 
found or the end of list is reached. If a URL cannot be loaded, 
some browser-specific mechanism is used to notify the user. 
Implementations may either block on a loadWorld() until the new 
URL finishes loading, or may return immediately and at some 
later time (when the load operation has finished) replace the 
current scene with the new one. 

public static Node createVrmlFromURL( String] url ); 
public static Node createVrmlFromString( String vrmlSyntax 


ys 


The create VrmlFromString() method takes a string consisting of 
a VRML scene description and returns the root node of the corre- 
sponding VRML scene. The createVRMLFromURL() asks the 
browser to load a VRML scene description from the given URL or 
URLs, returning the root node of the corresponding VRML scene. 
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public void addRoute(Node fromNode, String fromEventOut, 
Node toNode, String toEventIn); 

public void deleteRoute(Node fromNode, String fromEventOut , 
Node toNode, String toEventIn); 


These methods respectively add and delete a route between the 
given event names for the given nodes. 
public void bindBackground(Node background); 


public void unbindBackground( ); 
public boolean isBackgroundBound(Node background) ; 


bindBackground() allows a script to specify which Background 

node should be used to provide a backdrop for the scene. Once a 
Background node has been bound, isBackgroundBound() indi- 
cates whether a given Background node is the currently bound 
one, and unbindBackground() restores the Background node in 
use before the previous bind. If unbindBackground() is called 
when nothing is bound, nothing happens. Changing the fields of a 
currently bound Background node changes the currently dis- 
played background. 

public void bindNavigationInfo(Node navigationInfo); 

public void unbindNavigationInfo(); 

public boolean isNavigationInfoBound(Node navigationInfo); 


bindNavigationInfo() allows a script to specify which 

NavigationInfo node should be used to provide hints to the 
browser about how to navigate through a scene. Once a 
NavigationInfo node has been bound, isNavigationInfoBound() 
indicates whether a given node is the currently bound one, and 
unbindNavigationInfo() restores the NavigationInfo node in use 
before the previous bind. If unbindNavigationInfo() is called 
when nothing is bound, nothing happens. A script can change the 
fields of a NavigationInfo node using events and routes. Changing 
the fields of a currently bound NavigationInfo node changes the 
associated parameters used by the browser. 

public void bindViewpoint(Node viewpoint); 

public void unbindViewpoint(); 

public boolean isViewpointBound(Node viewpoint); 
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In some cases, a script may need to manipulate the user’s 
current view of the scene. For instance, if the user enters a vehicle 
(such as a roller coaster or elevator), the vehicle’s motion should 
also be applied to the viewer. bind Viewpoint() provides a way to 
bind the viewer to a given Viewpoint node. This binding doesn’t 
itself change the viewer location or orientation; instead, it changes 
the fields of the given Viewpoint node to correspond to the cur- 
rent viewer location and orientation. (It also places the viewer in 
the coordinate space of the given Viewpoint node.) Once a View- 
point is bound, the script can animate the transformation fields of 
the Transform that the Viewpoint is in (probably using an interpo- 
lator to generate values) and move the viewer through the scene. 

Note that scripts should animate the Viewpoint’s frame of 
reference (the transformation of the enclosing Transform) rather 
than the Viewpoint itself, in order to allow the user to move the 
viewer a little during transit (for instance, to let the user walk 
around inside the elevator while it’s between floors). Fighting 
with the user for control of the viewer is a bad idea. 

Note also that results are undefined for vehicle travel if the user 
is allowed to move out of the vehicle while the animation is 
running. This problem is best resolved by using collision detection 
to prevent the user leaving the vehicle while it’s in motion. An- 
other option is to turn off the browser’s user interface during 
animation by setting the current navigation type to “none”. 

When the script has finished transporting the user, 
unbindViewpoint() releases the viewer from the influence of the 
currently bound Viewpoint, returning the viewer to the coordinate 
space of the previous viewpoint binding (or the base coordinate 
system of the scene if there’s no previous binding). The fields of 
the now-unbound Viewpoint node return to the values they had 
before the binding. 

And of course isViewpointBound() returns TRUE if the speci- 
fied Viewpoint node is currently bound to the viewer (which 
implies that the fields of that Viewpoint node indicate the current 
position and orientation of the viewer). The method returns 
FALSE if the specified Viewpoint is not bound. 
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System and Networking Libraries 


Scripts that need to use system and networking calls should use 
the scripting language’s system and networking libraries. The 
VRML API doesn’t provide such calls. 


Scripting Example 


A Script node that decided whether or not to open a bank vault 
might receive vaultClosed and combinationEntered messages, 
produce openVault messages, and remember the correct combina- 
tion and whether or not the vault is currently open. The VRML for 
this Script node might look like this: 


DEF OpenVault Script { 
# Declarations of what's in this Script node: 
eventIn SFBool vaultClosed 
eventIn SFString combinationEntered 
eventOut SFBool openVault 
field SFString correctCombination "43-22-9" 
field SFBool currentlyOpen FALSE 


# Implementation of the logic: 
scriptType "java" 
behavior "java.class" 


} 


The “java.class” file will contain a compiled version of the 
following Java source code: 


import vrml; 
class VaultScript extends Script { 


// Declare fields 

private SFBool currentlyOpen = (SFBoo1 ) 
getField("currently0Open"); 

private SFString correctCombination = (SFString) 
getField("correctCombination"); 


// Declare eventOuts 
private SFBool openVault = (SFBool) 
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getEventOut("openVault" ); 


// Handle eventIns 

public void vaultClosed(ConstSFBool value, SFTime ts) { 
currentlyOpen.setValue(FALSE); 

} 


public void combinationEntered(ConstSFString combo, SFTime 
oe ee 
if (currentlyOpen.getValue() == FALSE && 
combo.getValue() == correctCombination) { 
currentlyOpen.setValue(TRUE) ; 
openVault.setValue( TRUE); 
} 
} 
} 


68 Exploring Moving Worlds 


chapter four 


Design Considerations 


pe chapter describes the “why” of the Moving Worlds 
VRML 2.0 proposal—why design decisions were made, 
why things were changed from VRML 1.0. It is written for 
armchair VRML designers and for the people who will be 
implementing VRML 2.0. 

It contains the following sections: 


WS Simplifying the Scene Structure 

WS Prototypes 

Extensibility 

WS Why Routes? 

Implementing and Optimizing Routes 
WS Scene Graph? WHAT Scene Graph? 

Y Transforms, Events, NodeReference 
WS Script Node API 

N 


Materials 
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Simplifying the Scene S$ 


There has been a lot of feedback from people implementing VRML 
1.0 that the very general scene structure and property inheritance 
model of VRML 1.0 makes its implementation unnecessarily 
complex. Many rendering libraries (such as RealityLab, 
RenderMorphics, IRIS Performer) have a simpler notion of render- 
ing state than VRML 1.0. The mismatch between these rendering 
libraries and VRML causes performance problems and implemen- 
tation complexity, and these problems become much worse in 
VRML 2.0 as we add the ability to change the world over time. 

To ensure that VRML 2.0 implementations are low-memory and 
high performance, the Moving Worlds VRML 2.0 proposal makes 
two major changes to the basic structure of the node hierarchy: 


1. Shape properties (material, texture, shapeHints) are moved to 
become an integral part of the shape. 

2. Transformation and Separator nodes are combined, so that a 
Transform defines a coordinate system relative to its parent. 


To make this change, two new nodes are introduced (the Shape 
and Appearance nodes), several are removed (Translate, Rotate, 
Scale, Separator, and MatrixTransform), and a few nodes are 
changed (Transform, IndexedFaceSet); this change has the added 
benefit of making VRML simpler. 


Design 


The decisions on how to partition functionality into separate 
objects were motivated mainly by considerations of what should 
or should not be individually sharable. Sharing (DEF/USE in 
VRML 1.0, also known as “cloning” or “multiple instancing”) is 
very important, since it allows many VRML scenes to be much 
smaller on disk (which means much shorter download times) and 
much smaller in memory. 

One extreme would be to allow absolutely ANYTHING in the 
VRML file to be shared, even individual numbers of a multiple- 
valued field. Allowing sharing on that fine a level becomes an 
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implementation problem if the values are allowed to change— 
and the whole point of behaviors is to allow values in the scene to 
change. Essentially, some kind of structure must be kept for 
anything that can be shared that may also later be changed. 

We considered allowing any field to be shared, but we believe that 
even that is too burdensome to implementations, since there may 
not be a one-to-one mapping between fields in the VRML file and 
the implementation’s in-memory data structures. 

VRML 1.0 allows nodes to be shared (via DEF/USE), and 
allowing sharing of any node seems reasonable, especially since 
events (the mechanism for changing the scene graph) are routed to 
nodes and because as much compatibility with VRML 1.0 as 
possible is one of the goals of the Moving Worlds proposal. 


Shape 


A new node type is introduced—the Shape node. It exists only to 
contain geometry and appearance information, so that 
geometry+appearance may be easily shared. It contains only two 
fields; the geometry field must contain a geometry node 
(IndexedFaceSet, Cube, etc.) and the appearance field may contain 
one or more appearance properties (Material, Texture2, etc.): 
Shape { 
field SFNode appearance 
field SFNode geometry 


The three-way decomposition of shapes (Shape/Geometry / 
Appearance) was chosen to allow sharing of entire shapes, just a 
shape’s geometry, or just the properties. For example, the pieces of 
a wooden chair and a marble table could be re-used to create a 
wooden table (shares the texture of the wooden chair and the 
geometry of the marble table) and/or to create multiple wooden 
chairs. 

It is an error to specify the same property more than once in the 
appearance array, and doing so will result in undefined results. 
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Geometry 


SS 


The existing VRML 1.0 geometry types are modified as necessary 
to include the geometric information needed to specify them. For 
example, a vertexData field is added to the IndexedFaceSet node 
to contain Coordinate3, TextureCoordinate2 and Normal nodes 
that define the positions, texture coordinates and normals of the 
IndexedFaceSet’s geometry. In addition, the fields of the 
ShapeHints node are added to IndexedFaceSet. 

These changes make it much easier to implement authoring 
tools that read and edit VRML files, since a Shape has a very well- 
defined structure with all of the information necessary to edit the 
shape contained inside of it. They also make VRML “cleaner”— 
for example, in VRML 1.0 the only shape that pays attention to the 
ShapeHints node is the IndexedFaceSet. Therefore, it makes a lot 
of sense to put the ShapeHints information INSIDE the 
IndexedFaceSet. 


Groups 


Shapes and other “Leaf” classes (such as Cameras, Lights, Envi- 
ronment nodes, Info nodes, etc.) are collected into a scene hierar- 
chy with group nodes such as Transform and LOD. Group nodes 
may contain only other group nodes or leaves as children; adding 
an appearance property or geometry directly to a group node is an 
error. 

VRML 1.0 had a complicated model of transformations; trans- 
formations were allowed as children of group nodes and were 
accumulated across the children. This causes many implementa- 
tion problems even in VRML 1.0 with LOD nodes that have 
transformations as children; the addition of behaviors would only 
make those problems worse. 

Allowing at most one coordinate transformation per group 
node results in much faster and simpler implementations. Decid- 
ing which group nodes should have the transformation informa- 
tion built-in is fairly arbitrary; obvious choices would be either 
“all” or “one.” Because we believe that transformations for some 
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of the group nodes (such as LOD) will rarely be useful and main- 
taining fields with default values for all groups will be an imple- 
mentation burden, we have chosen “one” and have added the 
fields of the old VRML 1.0 Transform nodes to the Transform 
node: 


Transform { 


field SFVec3f translation 000 
field SFRotation rotation 001 0 
field SFVec3f scaleFactor ey ae 
field SFRotation scaleOrientation 001 0 
field SFVec3f center 000 
field SFVec2f textureTranslation 0 0 
field SFFloat textureRotation 0 

field SFVec2f textureScaleFactor 1 1 
field SFVec2f textureCenter 0 0 


These allow arbitrary translation, rotation and scaling of either 
coordinates or texture coordinates. 

Side note: we are proposing that the functionality of the 
MatrixTransform node NOT be supported, since most implemen- 
tations cannot correctly handle arbitrary 4 X 4 transformation 
matrices. We are willing to provide code that decomposes 4 X 4 
matrices into the above form, which will take care of most current 
uses of MatrixTransform. The minority of the VRML community 
that truly need arbitrary 4 X 4 matrices can define a 
MatrixTransform extension with the appropriate field. 


Classes 


The nodes that can appear in a world are grouped into the follow- 
ing categories: 


Groups: 
Transform, LOD, Switch, WWWaAnchor 
Group nodes may ONLY have other groups or leaves as children. 
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Leaves: 

Shape, Lighting, Cameras, Info-type nodes (Info, WorldInfo, etc.) 
Leaf nodes are things that exist in one or more coordinate systems 
(defined by the groups that they are part of). 


Geometry: 

IndexedFaceSet, IndexedLineSet, PointSet, Sphere, Cube, etc. 
Geometry nodes are contained inside Shape nodes. They in turn 
contain geometric properties. 


Geometric properties: 
Coordinate3, Normal, TextureCoordinate2 
Are contained inside geometry. 


Appearance properties: 

Material, Texture2 

Are contained inside Appearance nodes, which are contained 
within Shapes, and define the shape’s appearance. 


Geometric Sensors: 

ClickSensor, PlaneSensor 

Are contained inside Transforms, and generate events with respect 
to the Transform’s coordinate system and geometry. 


WWWihline: 


WWWlunline cuts across all of the above categories (assuming that 
it is useful to externally reference any of the above). 


Nodes: 
All of the above, plus TimeSensors and Script nodes, which are 
not part of the world’s transformational hierarchy. 

Nodes contain data (stored in fields), and may be prototyped 
and shared. 
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Why Appearance in a Separate Node? 


Bundling properties into an Appearance node simplifies sharing, 
decreases file and run-time bloat, and mimics modeling paradigms 
where one creates a palette of appearances (“materials”) and then 
instances them when building geometry. Without Appearances, 
there is no easy way of creating and identifying a “shiny wood 
surface” that can be shared by the kitchen chair, the hardwood 
floor in the den, and the Fender Strat hanging on the wall. 

Another major concern of VRML in general and the Appearance 
node in particular is expected performance of run-time implemen- 
tations of VRML. It is important for run-time data structures to 
closely correspond to VRML; otherwise browsers are likely to 
maintain 2 distinct scene graphs, wasting memory as well as time 
and effort in keeping the 2 graphs synchronized. 

The Appearance node offers 2 distinct advantages for imple- 
mentations: 


1. Memory is saved in the Shape node since it has only a single 
pointer to an Appearance node rather than many pointers to 
individual property nodes. In my experience there are orders- 
of-magnitude more Shape nodes than Appearance nodes, so 
any memory bloat in Shape is a problem. As VRML expands to 
include more property nodes, Shape bloat becomes even more 
of an issue. 

2. The Appearance node facilitates state sorting and other opti- 
mizations that are applicable to both hardware and software 
implementations. For example, an implementation can quickly 
determine if 2 shapes have the same appearance by checking 
for pointer equality rather than comparing every property 
reference of a shape. As another example, the Appearance 
node offers a good place to maintain a cache which in the case 
of a software implementation may be a pre-wired path of 
rendering modules. 
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Prototypes 


There are several different ways of thinking about prototypes: 


WS Anextensibility mechanism that allows a new node to be 


\S 


Wb 


¥ 


Y 


Wy 


defined in terms of other, pre-defined nodes. Prototypes 
can replace all of the existing VRML 1.0 extension mecha- 
nisms (isA and fields[]). 


A protection mechanism that allows an author to limit 
what can be done to an object. EXTERNPROTO allows 
authors to specify how their worlds/objects/behaviors can 
be used within other worlds/objects/behaviors. 


An object-definition mechanism that allows somebody to 
define objects with specific (standardized) operations 
allowed. Prototypes allow application-specific policies to be 
imposed on the general scene structure. 


A convenience mechanism that allows geometry and/or 
behavior to be packaged in a convenient way. 


An optimization mechanism that allows browsers to reason 
about which object can or cannot be changed. 


A bandwith-saving mechanism that allows the definition of 
a world structure to be defined once and re-used multiple 
times. 


The Prototype Declaration 


A prototype’s interface is declared using one of the following 
syntaxes: 


PROTO name [ field fieldType name defaultValue 


eventIn fieldType name 
eventOut fieldType name 
] { implementation } 


EXTERNPROTO name [ field fieldType name 


eventIn fieldType name 
eventOut fieldType name 
] URL(s) 
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(There may be any number of field/eventIn/eventOut declara- 
tions in any order.) 

A prototype just declares a new kind of node; it does not create 
a new instance of a node and insert it into the scene graph, that 
must be done by instantiating a prototype instance. 

First, why do we need to declare a prototype’s interface at all? 
We could just say that any fields, eventIns or eventOuts of the 
nodes inside the prototype’s implementation exposed using the IS 
construct (see below) are the prototype’s interface. As long as the 
browser knows the prototype’s interface it can parse any proto- 
type instances that follow it. 

The declarations are necessary for EXTERNPROTO because a 
browser may not be able to get at the prototype’s implementation. 
Also requiring them for PROTO makes the VRML file both more 
readable (it is much easier to see the PROTO declaration rather 
than looking through reams of VRML code for nodes with IS) and 
makes the syntax more consistent. 

Default values must be given for a prototype’s fields so that 
they always have well-defined values (it is possible to instantiate a 
prototype without giving values for all of its fields, just like any 
other VRML node). Default values must not be specified for an 
EXTERNPROTO because the default values for the fields will be 
defined inside the URL that the EXTERNPROTO refers to. 

EXTERNPROTO refers to one or more URLs, with the first URL 
being the preferred implementation of the prototype and any 
other URLs defining less-desirable implementations. Browsers 
will have to be able to deal with the possibility that an 
EXTERNPROTO’s implementation cannot be found because none 
of the URL’s are available (or the URL array is empty!); browsers 
may also decide to “delay-load” a prototype’s implementation 
until it is actually needed (like they do for the VRML 1.0 
WWWiuhline node). 

Browsers can properly deal with EXTERNPROTO instances 
without implementations. Events will never be generated from 
such instances, of course, so that isn’t a problem. The browser can 
decide to either throw away any events that are routed to such an 
instance or to queue them up until the implementation does 
become available. If it decides to queue them up, the results when 
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they’re finally processed by the prototype’s implementation could 
be indeterminate IF the prototype generates output events in 
response to the input events. A really really smart browser could 
deal with this case by performing event rollback and roll-forward, 
re-creating the state of the world (actually, only the part of the 
world that can possibly be influenced by the events generated 
from the prototype need to be rolled forward /back) when the 
events were queued and “re-playing” input events from there. 
The fields of a prototype are internal to it, and a browser needs 
to know their current and default values only to properly create a 
prototype instance. Therefore, if the browser cannot create proto- 
type instances (because the prototype implementation is not 
available) the default values of fields aren’t needed. So, 
EXTERNPROTO provides all the information a browser needs. 


The Prototype Implementation 


The prototype’s implementation is surrounded by curly braces to 
separate it from the rest of the world. A prototype’s implementa- 
tion creates a new name scope—any names defined inside a 
prototype implementation are available only inside that prototype 
implementation. In this way a prototype’s implementation can be 
thought of as if it is a completely separate file. Which, of course, is 
exactly what EXTERNPROTO does. 

There’s an interesting issue concerning whether or not things 
defined outside the prototype’s implementation can be USEd 
inside of it. We think that defining prototypes such that they are 
completely self-contained (except for the information passed in 
via eventIn or field declarations) is wisest. 

The node type of a prototype is the type of the first node of its 
implementation. So, for example, if a prototype’s implementation 
is: 


{ IndexedFaceSet { ... } } 


Then the prototype can only be used in the scene wherever an 
IndexedFaceSet can be used (which is in the geometry field of a 
Shape node). The extra curly braces allow Scripts, TimeSensors 
and ROUTES to be part of the prototype’s implementation, even 
though they’re “off to the side” of the prototype’s scene graph. 


Chapter 4: Moving Worlds Design Considerations 79 


The IS syntax for specifying what is exposed inside a 
prototype’s implementation was suggested by Conal Elliott of 
Microsoft. It was chosen because: 


it removed some ambiguities that could arise about what a 
prototype’s field’s default values were in a previous syntax. 


it doesn’t require nodes to be given names just to expose 
them in the prototype. 


YW 


it allows fan-in (one eventIn or field going to multiple 
nodes in the prototype implementation). 


I 


it matches traditional programming languages better. 


Instantiating a Prototype 


Once a PROTO or EXTERNPROTO has been declared, a prototype 
can be instantiated and treated just like any built-in node. In fact, 
built-in nodes can just be treated as if there are a set of pre-defined 
PROTO definitions available at start-up in all VRML browsers. 

Each prototype instance is independent from all others— 
changes to one instance do not affect any other instance. Concep- 
tually, each prototype instance is equivalent to a completely new 
copy of the prototype implementation. 

However, even though prototype instances are conceptually 
completely separate, they can be implemented so that information 
is automatically shared between prototype instances. For example, 
consider this PROTO: 

PROTO Foo [ eventIn SFVec3f changeTranslation ] { 

Transform { 
translation IS changeTranslation 
Shape { 
. geometrytproperties stuff... 


} 


Because the translation of the Transform is the only thing that 
can possibly be changed, either from a ROUTE or from a Script 
node, only the Transform needs to be copied. The same Shape 
node may be shared by all prototype instances. 
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Script nodes that contain SFNode/MFNode fields (or may 
receive SFNode/MFNode events) can be treated in a similar way; 
for example: 


PROTO Foo [ eventIn SFFloat doSomething ] { 
DEF Root Transform { 
 SUUTT: 2.3 

} 
DEF MyScript Script { 

eventIn doIt IS doSomething 

field SFNode whatToAffect USE Root 

. other script stuff... 


In this case, a brand-new copy of everything inside Foo will 
have to be created for every prototype instance because MyScript 
may modify the Root Transform or any of its children using the 
script API. Of course, if some of the Transform’s children are 
prototype instances the browser might be able to optimize them. 

# A Transform that cannot be changed: 

# 

PROTO ConstantTransform [ 

field MFNode children 


field SFVec3f translation 000... etc for other 
fields... 
J] { 
Transform { children IS children 
translation IS translation ... etc... 


} 


We can imagine variations on the above—Transforms with 
transformations that can be changed, but children that can’t, 
transformations that can’t but children that can, etc. 
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Extensibility 


By extending the syntax of a URL in an EXTERNPROTO, all of the 
current and proposed extensibility mechanisms for VRML can be 
handled. 

The idea is to use the URL syntax to refer to an internal or built- 
in implementation of a node. For example, imagine your system 
has a Torus geometry node built-in. The idea is to use 
EXTERNPROTO to declare that fact, like this: 

EXTERNPROTO Torus [ field SFFloat bigRadius 


field SFFloat smal1Radius ] 
"internal: Torus" 


URLs of the form “internal:name” tell the browser to look for a 
“native” implementation (perhaps searching for the implementa- 
tion on disk, etc.). 

Just as in any other EXTERNPROTO, if the implementation 
cannot be found, the browser can safely parse and ignore any 
prototype instances. 

The ‘alternateRep’ notion is handled by specifying multiple 
URLs for the EXTERNPROTO: 

EXTERNPROTO Torus [ field SFFloat bigRadius 

field SFFloat smallRadius ] 
[ "internal:Torus", "http://machine/directory/protofile" ] 


So, if a “native” implementation of the Torus can’t be found, an 
implementation is downloaded from the given machine/ direc- 
tory /protofile—the implementation would probably be an 
IndexedFaceSet node with a Script attached that computes the 
geometry of the torus based on bigRadius and smallRadius. 

The ‘isA’ notion of VRML 1.0 is also handled using this mecha- 
nism. The ExtendedMaterial example from the VRML 1.0 spec: 

ExtendedMaterial { 

fields [ MFString isA, MFFloat indexOfRefraction, 
MFColor ambientColor, MFColor diffuseColor, 
MFColor specularColor, MFColor emissiveColor, 
MFFloat shininess, MFFloat transparency ] 
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isA [ "Material" ] 

indexOfRefraction .34 

diffuseColor .8 .54 1 
} 


becomes: 


PROTO ExtendedMaterial [ 
field MFFloat indexOfRefraction 0 
field MFColor ambientColor [000 ] 
field MFColor diffuseColor [ .8 .8 .8 ] 
. etc, rest of fields... ] 


Material { 
ambientColor IS ambientColor 
diffuseColor IS diffuseColor 
LO EEe: ax 


} 


ExtendedMaterial { 
indexOfRefraction .34 
diffuseColor .8 .54 1 


This nicely cleans up the rules about whether or not the fields of 
a new node must be defined only the first time the node appears 
inside a file or every time the node appears in the file (the PROTO 
or EXTERNPROTO must appear one before the first node in- 
stance). And it makes VRML simpler. 


Why Routes? 


Several different architectures for applying changes to the scene 
graph were considered before settling on the ROUTE syntax. This 
section documents the arguments for and against the alternative 
architectures. 
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All-API Architecture 


One alternative is to try to keep all behaviors out of VRML, and 
do everything inside the scripting API. 

In this model, a VRML file looks very much like a VRML 1.0 
file, containing only static geometry. In this case, instead of load- 
ing a .wrl VRML file into your browser, you would load some 
kind of .script file that then referenced a .wrl file and then pro- 
ceeded to modify the objects in the .wrl file over time. This is 
similar to conventional programming; the program (script) loads 
the data file (VRML .wrl file) and then proceeds to make changes 
to it over time. 

One advantage of this approach is that it makes the VRML file 
format simpler. A disadvantage is that the scripting language may 
need to be more complex. 

The biggest disadvantage, however, is that it is difficult to 
achieve good optimizibility, scalability and composability— three 
of our most important goals. 

In VRML 1.0, scalability and composability are accomplished 
using the WWWinhline node. In an all-API architecture, some 
mechanism similar to WWWInline would have to be introduced 
into the scripting language to allow similar scalability and 
composability. That is certainly possible, but putting this function- 
ality into the scripting language severely affects the kinds of 
optimizations that browsers are able to perform today. 

For example, the browser can pay attention to the direction that 
a user is heading and pre-load parts of the world that are in that 
direction if the browser knows where the WWWInline nodes are. 
If the WWWinhline concept is moved to the scripting language the 
browser probably will NOT know where they are. 

Similarly, a browser can perform automatic behavior culling if it 
knows which parts of the scene may be affected by a script. For 
example, imagine a lava lamp sitting on a desk. There is no reason 
to simulate the motion of the blobs in the lamp if nobody is look- 
ing at it—the lava lamp has a completely self-contained behavior. 
In an API-only architecture, it would be impossible for the 
browser to determine that the behavior was self-contained; how- 
ever, with routes, the browser can easily determine that there are 
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no routes into or out of the lava lamp, and that it can therefore be 
safely behavior culled. (Side note: we do propose flags on Scripts 
for cases in which it is important that they NOT be automatically 
culled.) 

Another disadvantage to this approach is that it allows only re- 
use of geometry. Because the behaviors must directly load the 
geometry, it is impossible to “clone” a behavior and apply it to 
two different pieces of geometry, or to compose together 
behavior+geometry that can then be re-used several times in the 
same scene. 

The disconnect between the VRML file and the script file will 
make revision control painful. When the VRML file is changed, 
the script may or may not have to be changed— in general, it will 
be very difficult for a VRML authoring system to maintain worlds 
with behaviors. If the VRML authoring system cannot parse the 
scripting language to find out what it refers to in the VRML file, 
then it will be impossible for the authoring system to ensure that 
behaviors will continue to work as the VRML file is edited. 


All-VRML Architecture 


Another alternative is to extend VRML so that it becomes a com- 
plete programming language, allowing any behavior to be ex- 
pressed in VRML. 

The main disadvantage to this approach is that it requires 
inventing Yet Another Scripting Language, and makes implemen- 
tation of a VRML browser much more complicated. If the lan- 
guage chosen is very different from popular languages, there will 
be very few people capable of programming it and very little 
infrastructure (classes, books, etc.) to help make it successful. 

Writing a VRML authoring system more sophisticated than a 
simple text editor becomes very difficult if a VRML file may 
contain the equivalent of an arbitrary program. Creating ANY 
VRML content becomes equivalent to programming, which will 
limit the number of people able to create interesting VRML 
worlds. 
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The main advantage to an all-VRML architecture is the oppor- 
tunity for automatic optimizations done by the browser, since the 
browser knows everything about the world. 


Routes and Script Nodes Architecture 


The alternative we chose was to treat behaviors as “black boxes” 
(Script nodes) with well-defined interfaces (routes and fields). 

Treating behaviors as black boxes allows any scripting language 
to be used (Java, Visual Basic, ML, whatever) without changing 
the fundamental architecture of VRML. Implementing a browser 
becomes much easier because only the interface between the scene 
and the scripting language needs to be implemented, not the 
entire scripting language. 

Expressing the interface to behaviors in the VRML file allows an 
authoring system to intelligently deal with the behaviors, and 
allows most world creation tasks to be done with a graphical 
interface. A programming editor only need appear when a sophis- 
ticated user decides to create or modify a behavior (opening up 
the black box, essentially). The authoring system can safely ma- 
nipulate the scene hierarchy (add geometry, delete geometry, 
rename objects, etc.) without inadvertently breaking connections 
to behaviors. 

The existing VRML composability and scalability features are 
retained, and because the possible effects of a behavior on the 
world are known to the browser, most of the optimizations that 
can be done in an all-VRML architecture can still be done. 


Implementing and Optimizing Routes 


This section gives some “thumb-nail” design for how a browser 
might decide to implement routes. It points out some properties of 
the routes design that are not obvious at first glance and that can 
make an implementation of routes simple and efficient. 

There doesn’t need to be any data copying at all as an event 
“travels” along a route. In fact, the event doesn’t need to “travel” 
at all—the ROUTE is really just a re-naming from the eventIn to 
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the eventOut that allows the composability, authorability, extensi- 
bility and scalability that are major goals of the Moving Worlds 
design. 

The data for an event can be stored at the source of the event— 
with the “eventOut”. The “eventIn” doesn’t need to store any 
data, because it is impossible to change an “eventIn”—it can just 
point to the data stored at the “eventOut”. That means that mov- 
ing an event along a ROUTE can be as cheap as writing a pointer. 
In fact, in the VERY common case in which there is no “fan-in” 
(there aren’t multiple eventOut’s routed into a single eventIn) NO 
data copying at all need take place—the eventIn can just point to 
eventOut since that eventOut will always be the source of its 
events. 

Exposed fields—fields that have corresponding eventOut’s— 
can share their value between the eventOut and the field itself, so 
very little extra overhead is imposed on “exposed” fields. Highly 
optimized implementations of nodes with exposed fields could 
store the data structures needed to support routes separately from 
the nodes themselves and use a dictionary mapping node pointers 
to routing structures, adding NO memory overhead for nodes that 
do not have routes coming into or out of them (which is the 
common case). 

Because the routing structures are known to the browser, many 
behavior-culling optimizations are possible. A two-pass 
notification+evaluation implementation will automatically cull 
out any irrelevant behaviors without any effort on the part of the 
world creator. The algorithm works by delaying the execution of 
behaviors until their results are necessary, as follows: 

Imagine a TimeSensor that sends alpha events to a Script that in 
turn sends setDiffuseColor events to an object, to change the 
object’s color over time. Allocate one bit along each of these 
routes; a “dirty bit” that determines whether or not changes are 
happening along that route. The algorithm works as follows: 


1. Time changes. All routes from the TimeSensor are marked 
dirty, all the way through the routing network (from the 
TimeSensor, to the Script, to the object who’s material we’re 
changing). This “notification” process can stop as soon as a 
route that has already been marked “dirty” is reached. Most 
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browsers will probably let notification continue up through 
the children[] MFNode fields of groups; if the notification 
eventually reaches the root of the scene the browser will know 
that the scene must be redrawn. 

2. When (or before) the browser redraws the scene, any object 
that will be drawn that has a route to it with its dirty bit set 
must be re-evaluated by evaluating whatever is connected to it 
up-stream. When a route is evaluated, its dirty bit is cleared. 


This two-pass “push notification / pull events” algorithm has 
several nice properties: 


¥ 


\S 


¥ 


If an object cannot be perceived, its behavior does not need 
to be run. In the example of the changing material, if the 
object is never drawn, its material will not be needed. The 
TimeSensor may change, but the route from the TimeSensor 
to the Script will be dirty, so notification will stop right 
away. Note that TimeSensor is carefully defined such that 
only the last “time changed” event is guaranteed to be 
available, so you don’t even need to queue up all of the 
“time changed” events. In the case of a ClickSensor or 
something else where every event might be important, 
either events will have to be queued up OR scripts will 
have to be run as soon as there is more than one event 
waiting. 

If the behavior is affecting something like a transformation, 
then it will automatically always get run IF that transfor- 
mation is needed to compute the perceptibility of the 
object. If a maximum possible bounding box can be speci- 
fied by the world creator, then even behaviors that affect 
transformations need not get run. 


If the behavior is affecting something that cannot be seen, 
the scene doesn’t need to be redrawn. And it won’t be, 
because the notification process will stop at the first “dirty” 
route and will never reach the root of the scene graph. 


If the view changes so that something now CAN be seen, 
the scene will be redraw (because the view changed) and 
portions of the scene that were marked “dirty” that are now 
visible will be “clean”. 
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If you have to shadow things that are changing in your 
rendering library, the dirty bits will tell you exactly what 
changed so you can update your rendering library. 


Scene Graph? WHAT Scene Graph’? 


Moving Worlds has been carefully designed so that a browser will 
only need to keep the parts of the VRML scene graph that might 
be changed. There is a tradeoff between world creators who want 
to have control over the VRML scene graph structure and browser 
implementors who also want complete control over the VRML 
scene graph structure; Moving Worlds is designed to compromise 
between these two, allowing world creators to impose a particular 
structure on selected parts of the world while allowing browsers 
to optimize away the rest. 
One example of this is the routing mechanism. Consider the 
following route: 
Shape { 
appearance Appearance { 
material DEF M Material { ... } 
geometry Cube { } 


} 
ROUTE MyAnimation.color -> M.setDiffuseColor 


A browser implementor might decide not to maintain the 
Material as a separate object, but instead to route all 
setDiffuseColor events directly to the relevant shape(s). If the 
Material was used in several shapes then several routes might 
need to be established where there was one before, but as long as 
the visual results are the same the browser implementor is free to 
do that. 

There is a potential problem if some Script node has a pointer to 
or can get a pointer to the Material node. In that case, there will 
need to be at least a stand-in object for the Material (that forwards 
events on to the appropriate shapes) IF the Script might directly 
send events to what it thinks is the Material node. However, Script 
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nodes that do this MUST set the “directOutputs” flag to let the 
browser know that it might do this. And the browser will know if 
any Script with that flag set can get access to the Material node, 
because the only way Scripts can get access to Nodes is via a field, 
an eventIn, or by looking at the fields of a node to which it already 
has access. 

World creators can help browsers by limiting what Script nodes 
have access to. For example, a browser will have to maintain just 
about the entire scene structure of this scene graph: 


DEF ROOT Transform { 
children [ 
Shape { ... geometry Sphere{ } }, 
Transform { 
j SUEY <a 
} 
] 
} 
Script { 
directOutputs TRUE 
field SFNode whatToChange USE ROOT 


Because the Script has access to the root of the scene, it can get 
the children of that root node, send them events directly, add 
children, remove children, etc. 

However, this entire scene can be optimized below the Trans- 
form, because the browser KNOWS it cannot change: 


PROTO ConstTransform [ field MFNode children ] { 
Transform { children IS children } 
} 
DEF ROOT ConstTransform { 
children [ 
Shape { ... geometry Sphere{ } }, 
Transform { 
<%. SEUIE ews 
} 
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Script { 
unknownOutputs TRUE 
field SFNode whatToChange USE ROOT 


Because of the prototype interface, the browser KNOWS that 
the Script cannot affect anything inside the ConstTransform—the 
ConstTransform has NO exposed fields or eventin’s. If the 
ConstTransform doesn’t contain any sources of changes (Sensors 
or Scripts), then the entire subgraph can be optimized away— 
perhaps stored ONLY as a display list for a rendering library, or 
perhaps collapsed into a “big bag of triangles” (also assuming that 
there are no LODs, of course). 

The other nice thing about all this is that a PROTO or 
EXTERNPROTO (or WWWinline, which is pretty much equiva- 
lent to a completely opaque prototype) can be optimized indepen- 
dently of everything else, and the less control an author gives over 
how something might be changed, the more opportunities for 
optimizations. 


Transforms, Events, NodeReference 


The children of a Transform (or other group node) are kind of 
strange—they aren’t specified like fields in the VRML 1.0 syntax. 
Issue: They could be—they are functionally equivalent to an 

MFNode field. For example, this: 


# Old syntax? 
Transform { 
Transform { ... } 
Transform { ... } 


is equivalent to the slightly wordier: 


# New syntax? 
Transform { 
children [ 
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TPARSTORM (xa G 
Transform { ... } 
] 

... Where “children” is an MFNode field. The issue is whether or 
not we should keep the VRML 1.0 syntax as a convenient short- 
hand that means the same as the wordier syntax. The advantages 
are that it would make the VRML file syntax easier to parse and 
would eliminate some ambiguities that can arise if fields and 
nodes are allowed to have the same type names. The disadvan- 
tages are that it would make VRML files slightly bigger, is less 
convenient to type in, and is a change from VRML 1.0 syntax. 

In any case, to allow grouping nodes to be used as prototypes 
and to allow them to be seen in the script API, their children must 
“really” be an MFNode field. So a Transform might be specified 
as: 

PROTO Transform [ 

field SFVec3f translation 0 0 0 
eventIn SFVec3f setTranslation 
eventOut SFVec3f translationChanged 
... etc for the other transformation fields... 
field MFNode children [ ] 
eventIn MFNode setChildren 
eventOut MFNode childrenChanged 


Specifying events corresponding to the children field implies 
that the children of a Transform can change—that the structure of 
the scene can be changed by behaviors. 

Setting all of the children of a Transform at once (using 
setChildren) is inconvenient; although not strictly necessary, the 
following might be very useful: 


eventIn MFNode addChildren 
eventIn MFNode removeChildren 


Sending an addChildren event to the Transform would add all 
of the children in the message to the Transform’s children. Send- 
ing a removeChildren event would remove all of the children in 
the message. 


Cx 


Script Node: 
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The Transform node’s semantics were carefully chosen such 
that the order of its children is irrelevant. That allows a lot of 
potential for implementations to re-order the children either 
before or during rendering for optimization purposes (for ex- 
ample, draw all texture-mapped children before all non-texture 
mapped children, or sort the children by which region of space 
they’re in, etc.). The addChildren/removeChildren events main- 
tain this property—anything using them doesn’t need to concern 
itself with the order of the children. 

A previous version of Moving Worlds had a node called 
“NodeReference” that was necessary to allow nodes to be inserted 
as children into the scene. Exposing the children of groups as 
MFNode fields eliminates the need for something like 
NodeReference. 


Minimal API 


This section describes the API from the point of view of somebody 
using VRML to create behaviors. At least the following functional- 
ity will be necessary: 


init/destroy/processEvents 
The browser must call the user’s init routine before calling 
processEvents or destroy. 

The processEvents routine may be called any time between init 
and destroy, and will usually process all waiting events and 
generate events and/or modify the Script node’s fields. 

The browser must call the destroy routine to allow the script an 
opportunity to do cleanup. After destroy is called, processEvents 
must not be called until after another init is done. 


getiset fields 

The fields of a script node must be accessible from the API. That 
implies that the VRML field types (SFFloat, MFFloat, etc.) must 
somehow be exposed in the API. 
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send/receive events 
The processEvents routine must have access to a list of events 
received from things routed to it. Each event will have: 


w Name 
Type (any of the field types) 


Value (same as field value) and API to get/set the event’s 
contents (both get and set for events that will be output, 
only get for events that come in) 


S Timestamp 


Synchronization API 


To support scripting languages such as Java which allow the 
creation of asynchronous processes (threads), some mechanism for 
synchronizing with the browser when changing the Script’s fields 
and generating events is necessary. At the very least, a mechanism 
to “bracket” or “bundle up” a set of changes is necessary. 


Script Node: Node API 


Once a Script node has access to an SFNode or an MFNode value 
(either from one of the Script’s fields, or from an eventIn that 
sends the script a node), we must decide what operations a script 
can perform on them. A straw-man proposal: 


get/set “exposed” fields 

For any field “foo” of the node that has both a “setFoo” eventIn 
and a “fooChanged” eventOut, allow that field to be directly set 
and get. 


There should be API to get the list of exposed fields, of a given 
node. 


94 Exploring Moving Worlds 


get list of eventin/eventOut 

Given a node, there should be a way of determining what events it 
can send and receive. There should be some way of establishing a 
route from within a Script, assuming the script has somehow 
gotten access to the nodes on both ends of the route. 


“compileVRML” 

An API call that allows VRML file format contained in a string to 
be “compiled” into a Node from inside a script, allowing a Script 
node to receive file format from over the network, for example. 


communication with the browser 

The API must provide methods by which a Script node can com- 
municate with the browser to request operations such as loading a 
new URL as the world (to allow WWWAnchor-like functionality 
controlled by a Script), to get the current “simulation” time (which 
may be different from the current wall-clock time), etc. 


Convenience method: search by name/type 


Search for nodes by name or by type “under” a given node. 
Assuming that the children of group nodes is exposed in the API 
as an MFNode field called “children”, this is really a short-hand 
convenience way of performing something like: 


Node search(Node startingNode, ...criteria...) { 
for all fields of startingNode { 
if field type is SFNode { 
Node kid = contents of field 
if kid matches criteria, return kid 
else { 
Node Found = search(kid, criteria) 
if (Found != NULL) return Found 
} 
} 
else if field type is MFNode, for all values i { 
Node kid = value[i] 
if kid matches criteria, return kid 
else { 
Found = search(kid, criteria) 
if (Found != NULL) return Found 
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} 
} 
return NULL 


Throughout this discussion I’m assuming that access to 
prototyped nodes is restricted by the prototype’s interface. That 
will allow implementations to know what can and what can’t 
change, which will enable many optimizations. 


Materials 


The VRML 1.0 material specification is more general than cur- 
rently supported by most 3D rendering libraries and hardware. It 
is also fairly difficult to explain and understand; a simpler mate- 
rial model will make VRML 2.0 both easier to understand and 
easier to implement. 

First, the notion of per-vertex or per-face materials /colors 
should be moved from the Material node down into the geometric 
shapes that support such a notion (such as IndexedFaceSet). 
Doing this will make colors more consistent with the other per- 
vertex properties (normals and texture coordinates) and will make 
it easier for browsers to ensure that the correct number of colors 
has been specified for a given geometry, etc. 

The new syntax for a geometry such as IndexedFaceSet will be: 


IndexedFaceSet { 


exposedField SFNode coord NULL 
exposedField SFNode color NULL 
exposedField SFNode normal NULL 
exposedField SFNode texCoord NULL 


Anew node, similar to the Normal/TextureCoordinate2 nodes, 
is needed for the color field. It is often useful to define a single set 
of colors to function as a “color map” that is used by several 
different geometries, so the colors are specified in a separate node 
that can be shared. That node will be: 
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Color { 
exposedField MFColor rgb [ ] # List of rgb colors 
} 


The material parameters in the material node would all be 
single-valued, and we suggest that the ambientColor term be 
removed: 


Material { 
exposedField SFColor diffuseColor 0. 
exposedField SFColor specularColor 0 
exposedField SFColor emissiveColor 0 

0 
0 


6 0.8 


exposedField SFFloat shininess 
exposedField SFFloat transparency 


If multiple colors are given with the geometry, then they either 
replace the diffuse component of the Material node (if the material 
field of the Appearance node is not NULL) or act as an “emissive- 
only” source (if the material field of the Appearance node is 
NULL). 


Simplified Bindings 


Another complicated area of VRML 1.0 are all of the possible 
bindings for normals and materials—DEFAULT, OVERALL, 
PER_PART, PER_PART_INDEXED, PER_FACE, 
PER_FACE_ INDEXED, PER_VERTEX, and 
PER_VERTEX_INDEXED. Not all bindings apply to all geom- 
etries, and some combinations of bindings and indices do not 
make sense. 

A much simpler specification is possible that gives equivalent 
functionality: 


IndexedFaceSet { 
field MFInt32 coordIndex [ ] 


field MFInt32 colorIndex [ ] 
field SFBool colorPerVertex TRUE 
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field MFInt32 normal Index tics 
field SFBool normalPerVertex TRUE 
field MFInt32 texCoordIndex C ] 


te 


The existing materialBinding/normalBinding specifications are 
replaced by simple booleans that specify whether colors or 
normals should be applied per-vertex or per-face. If indices are 
specified, then they are used. If they are not specified, then either 
the vertex indices are used (if per-vertex normals/colors), OR the 
normals/colors are used in order (if per-face). 

In more detail: 


\S 


N 


If normals/colors are NOT specified, the browser should: 
—normals: generate automatically. 


—colors: just use Material specification from Appearance 
(like VRML 1.0 OVERALL). 


If normals/colors are specified (non-NULL normal/color 
field): 
o If normal/colorPerVertex is FALSE: 


+ If Index is not empty, then use indices to choose normals/ 
colors per face (equivalent to VRML 1.0 
PER_FACE INDEXED). 


+ Else use the normals/colors in order (equivalent to 
VRML 1.0 PER_FACE). 


o If normal/colorPerVertex is TRUE: 


+ If Index is not empty, then use indices to choose normals/ 
colors per vertex (equivalent to VRML 1.0 
PER_VERTEX_INDEXED). 


+ Else choose normals/colors using the coordIndex indices 
(also equivalent to VRML 1.0 PER_VERTEX_INDEXED). 
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Texture coordinates do not have a PerVertex flag, because 
texture coordinates are always specified per vertex. The rules for 
texture coordinates are the same as for per-vertex colors/normals: 
if texCoordIndex is empty, the vertex indices in coordIndex are 
used. 

IndexedLineSet would add color and colorPerVertex fields, 
with similar rules to IndexedFaceSet. PointSet would need only a 
color field (OVERALL color if empty, otherwise color-per-point). 
The shapes that allow PER_PART colors in VRML 1.0 (Cylinder, 
Cone) would also only need a color field (PER_PART colors if 
specified, OVERALL otherwise). 

Comparison with VRML 1.0: if all of the possibilities are written 
out, the only binding missing is the VRML 1.0 PER_VERTEX 
binding, which ignores the Index fields and just takes colors/ 
normals in order for each vertex of each face. For example, in 
VRML 1.0 if the coordIndex array contained [ 10, 12, 14, -1, 11, 13, 
10, -1 ] (two triangles with one shared vertex), then the 
PER_VERTEX binding is equivalent to a PER_VERTEX_INDEXED 
binding with indices [ 0, 1, 2, -1, 3, 4, 5, -1 ]—that is, each positive 
entry in the coordIndex array causes another color/normal to be 
taken from their respective arrays. VRML 1.0 files with 
PER_VERTEX bindings that are converted to VRML 2.0 will be 
somewhat larger, since explicit indices will have to be generated. 


chapter five 


i ie section provides a detailed description of each node in 
VRML 2.0. There is a helpful table of contents at the top organized 
functionally. However, the nodes are listed alphabetically. (An 
alphabetical Index of Nodes and Fields is also available.) 

This document’s URL: 
http: / /webspace.sgi.com/moving-worlds/spec/nodesRef.html. 


| Node Cross-Reference 


Lights and Lighting 


Grouping Nodes 


Anchor 
Billboard 
Collision 
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Group 
Inline 
LOD 
Switch 
Transform 


Leaf Nodes 


DirectionalLight 
Fog 

PointLight 

Shape 

Sound 

SpotLight 


Bindable Leaf Nodes 


Background 
NavigationInfo 
Viewpoint 


Sensor Nodes 


CylinderSensor 
DiskSensor 
PlaneSensor 
ProximitySensor 
SphereSensor 
TimeSensor 
TouchSensor 
VisibilitySensor 


Global Nodes 


SCrips 
WorldInfo 
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Geometry Nodes 


Box 

Cone 

Cylinder 
ElevationGrid 
Extrusion 
IndexedF aceSet 
IndexedLineSet 
PointSet 
Sphere 

Text 


Geometric Property Nodes 


Color 

Coordinate 

Normal 
TextureCoordinate 


Appearance Node and Appearance Property Nodes 


Appearance 
FontStyle 
ImageTexture 
Material 
MovieTexture 
PixelTexture 
TextureTransform 


Animation Interpolation Nodes 


ColorInterpolator 
CoordinateInterpolator 
Normal Interpolator 
OrientationInterpolator 
PositionInterpolator 
ScalarInterpolator 
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Media Nodes 
AudioClip 


TIP 
For field descriptions, see Chapter 6. 


General Node Types and How to Work With Them 


Appearance and Appearance Property Nodes 


The Material, Texture, and TextureTransform appearance property 
nodes are always contained within fields of an Appearance node. 
The FontStyle node is always contained in the fontStyle field of a 
Text node. 


Appearance 
FontStyle 
ImageTexture 
Material 
MovieTexture 
Pixel Texture 
TextureTransform 


Bindable Leaf Nodes 


The Background, NavigationInfo, and Viewpoint leaf nodes 
behave as all leaf nodes, except that only one of each type can be 
active at any point in time. Thus, the browser maintains a stack for 
each type of binding node (Background stack, NavigationInfo 
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stack, and Viewpoint stack). Each of these nodes includes a bind 
eventIn and an isBound eventOut. The bind eventlIn is used to 
push and pop a given node from its respective stack. A TRUE 
value sent to bind pushes the node to the top of the stack, and a 
FALSE pops it. The isBound eventOut is sent when the given 
node’s binding state changes (i.e., if pushed or popped). 


Bind Stack Behavior 

During read, the first encountered <binding node> is bound and a 
isBound eventOut is issued. When a bind TRUE eventIn is re- 
ceived by a <binding node> it is pushed to the top of the binding 
stack for that node type and becomes the currently bound <bind- 
ing node>, (and the isBound eventOut sends TRUE). When a bind 
FALSE eventlIn is received by the <binding node> on the top of the 
stack, it is popped from the stack and the next node in the stack 
becomes the currently bound <binding node>, (and the isBound 
eventOut sends FALSE). When a bind FALSE eventlIn is received 
by a <binding node> not on the top of the stack, it is removed 
from the stack but the currently bound <binding node> does not 
change. If a given <binding node> appears more than once in the 
stack and that node receives a bind FALSE eventIn, the one closest 
to the top of stack is removed. If a bind FALSE is received by a 
node not in the stack the event is ignored and an isBound event is 
not sent. If a pop of the last node on the stack is attempted the 
event is ignored and an isBound event is not sent. 


Bindable Nodes 


Background 
NavigationInfo 
Viewpoint 
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X vs. Specification Syntax 

is document, the last item in the node specifications is the 
blic interface for the node. The syntax for the public interface 
the same as that for that node’s prototype. This interface is 
he definitive specification of the fields, names, types, and de- 
fault values for a given node. Note that this syntax is not the 
actual file format syntax. However, the parts of the interface that 
are identical to the file syntax are in bold. For example, the fol- 
lowing defines the DirectionalLight node’s public interface: 


DirectionalLight { 


exposedField SFBool on TRUE 
exposedField SFFloat intensity 1 
exposedField SFFloat ambientIntensity 0 
exposedField SFColor color i a ae 
exposedField SFVec3f direction 0.0) =] 


Fields that have associated implicit set_ and _changed events 
are labeled exposedField. For example, the on field has a set_on 
input event and an on_changed output event. Exposed fields 
may be connected using ROUTE statements, and may be read 
and/or written by Script nodes. 

Note that this information is arranged in a slightly different 
manner in the actual file syntax. The keywords “field” or 
“exposedField” and the types of the fields (e.g. SFColor) are 
not specified when expressing a node in the file format. An ex- 
ample of the file format for the DirectionalLight is: 


DirectionalLight { 
on TRUE 
intensity 1 
ambientIntensity 0 
color 111 


1 
direction 0) 0 —1 
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Geometry Nodes 


A Shape node contains one geometry node in its geometry field. 
This node can be an IndexedFaceSet, IndexedLineSet, PointSet, or 
Text node. A geometry node can appear only in the geometry field 
of a Shape node. Geometry nodes usually contain Coordinate, 
Normal, and TextureCoordinate nodes in specified SFNode fields. 
All geometry nodes are specified in a local coordinate system 
determined by the parent(s) nodes of the geometry. 


Application of Material, Texture, and Colors 

The final rendered look of a piece of geometry depends on the 
Material and Texture in the associated Appearance node along with 
any Color node specified with the geometry (such as per-vertex 
colors for an IndexedFaceSet node). The following describes ideal 
behavior; implementations may be forced to approximate the ideal 
behavior Either a full-color (3 or 4 component) texture OR per- 
vertex /per-face colors should be specified; if both a full-color 
texture AND colors are specified, the colors will be ignored. 
Intensity-map (1 or 2 component) should ideally modulate the 
intensity of the object’s per-face/per-vertex colors or the diffuse 
color of the object’s material. If the material field of the Appear- 
ance node is not NULL, then any colors or texture specified 
should ideally take the place of the Material node’s diffuseColor 
field. If the material field of the Appearance node is NULL, then 
any colors or texture specified will make the geometry function as 
an emissive surface, unaffected by light sources. If no colors or 
textures are specified, then the surface should appear completely 
black (the default emissive color). 


Shape Hints Fields 

The ElevationGrid, Extrusion, and IndexedFaceSet nodes all have 
three SFBool fields that provide hints about the shape—whether it 
contains ordered vertices, whether the shape is solid, and whether 
it contains convex faces. These fields are ccw, solid, and convex. 
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The ccw field indicates whether the vertices are ordered in a 
counter-clockwise direction when the shape is viewed from the 
outside (TRUE). If the order is clockwise or unknown, this field 
value is FALSE. The solid field indicates whether the shape en- 
closes a volume (TRUE). If nothing is known about the shape, this 
field value is FALSE. The convex field indicates whether all faces 
in the shape are convex (TRUE). If nothing is known about the 
faces, this field value is FALSE. 

These hints allow VRML implementations to optimize certain 
rendering features. Optimizations that may be performed include 
enabling backface culling and disabling two-sided lighting. For 
example, if an object is solid and has ordered vertices, an imple- 
mentation may turn on backface culling and turn off two-sided 
lighting. If the object is not solid but has ordered vertices, it may 
turn off backface culling and turn on two-sided lighting. 


Crease Angle Field 

The creaseAngle field, used by the ElevationGrid, Extrusion, and 
IndexedFaceSet nodes, affects how default normals are generated. 
For example, when an IndexedFaceSet has to generate default 
normals, it uses the creaseAngle field to determine which edges 
should be smoothly shaded and which ones should have a sharp 
crease. The crease angle is the angle between surface normals on 
adjacent polygons. For example, a crease angle of .5 radians (the 
default value) means that an edge between two adjacent polygo- 
nal faces will be smooth shaded if the normals to the two faces 
form an angle that is less than .5 radians (about 30 degrees). 
Otherwise, it will be faceted. 


Geometric Property Nodes 


Geometric properties must be contained in the corresponding 
SFNode fields of geometry nodes such as the IndexedFaceSet, 
IndexedLineSet, and PointSet nodes. The following nodes are 
geometric properties: 

Color 

Coordinate 

Norma] 

TextureCoordinate 
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For example, the following IndexedFaceSet (contained in a 
Shape node) uses all four of the geometric property nodes to 
specify vertex coordinates, colors per vertex, normals per vertex, 
and texture coordinates per vertex (note that the material sets the 
overall transparency): 

Shape { . 

geometry IndexedFaceSet { 
coordIndex [ 0, 1, 3, -1, 0, 2, 5, -l, ...] 
{ potnt [0.0 5.0°3.0, 2.22] 


coord Coordinate 
} 
color Color { rgb [ 0.2 0.7 0.8, ...] 
} 
normal Normal { vector [0.0 1.0 0.0, 
Lah 


texCoord TextureCoordinate { point [0 1.0, ...] } 
} 
appearance Appearance { material Material { transparency 
0.5 FJ 
} 


Global Nodes 


The Script and WorldInfo nodes are not part of the world’s trans- 
formational hierarchy. 

WorldInfo nodes are global nodes that affect everything in the 
scene. They can be used anywhere in the scene description and 
may appear in fields of a Script node. If more than one WorldInfo 
node appears in a file, the first one encountered during read is the 
one that is used. 


Grouping Nodes 


Grouping nodes are container objects that have other nodes as 
children. Each grouping node treats its children in a different 
manner. 
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Interpolator Nodes 


Interpolator nodes are designed for linear keyframed animation. 
That is, an interpolator is simply a linear function, f(t), defined by 
n values of f(t) and n corresponding values of t, where t ranges 
from 0.0 to 1.0. An interpolator evaluates the linear function given 
a value of t (via the set_fraction eventIn). 

There are several different types of interpolator nodes, each 
based on the type of value that is interpolated (e.g. color vs. 
normal). All interpolator nodes share a common set of fields and 


semantics: 
exposedField MF<type> values Lose 
exposedField MFFloat keys Piel 
eventIn SFFloat set_fraction 


eventOut [S|M]F<type> outValue 


The values field specifies the actual values of the linear func- 
tion. The type of this multiple-valued field is dependent on the 
type of the interpolator (e.g. ColorInterpolator’s values field is of 
type MFColor). Each value in the values field corresponds in order 
to a parameterized time in the keys field. Therefore, there exists 
exactly the same amount of values in the values field as key 
values in the keys field. Values in the keys field are restricted to 
the 0.0 to 1.0 range; values outside of this range clamp up and 
down respectively. The values in the keys field must be increasing 
and non-repeating results are indeterminate if the keys values 
decrease or repeat. 

The set_fraction eventIn receives a float event in the 0.0 to 1.0 
range and causes the interpolator function to evaluate. The results 
of the linear interpolation are sent to outValue eventOut. 

Most interpolators output a single-valued field to outValue. 
However, there are some exceptions, such as CoordinateInterpolator 
and Normallnterpolator, that send multiple-value results to 
outValue. In this case, the values field is an nxm array of values, 
where n is the number of key values and m is the number of 
values per key. The following example illustrates a simple 
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ScalarInterpolator which contains a list of floats (11.0, 99.0, and 
33.0), the keyframe times of each scalar (0.0, 0.5, and 1.0), and 
outputs a single float value for a given time: 


ScalarInterpolator [ 


exposedField MFFloat keys LOH. 05, 1.0] 
exposedField MFFloat values [11.0, 99.0, 33.0] 
eventIn SFFloat set_fraction 


eventOut SFFloat outValue 


For a given key value of 0.25 (set_fraction), this 
ColorInterpolator would send an output value of: 


eventOut SFFloat outValue 55.0 
# = 11.0 + ((99.0-11.0)/(0.5-0.0)) * 0.25 


Whereas the CoordinateInterpolator below defines an array of 
coordinates for each keyframe value and sends an array of coordi- 
nates as output: 


CoordinateInterpolator [ 


exposedField MFFloat keys F020... 045, -1.08) 
exposedField MFVec3f values [0 0 0, 10 10 30,#0.0 
10 20 10, 40 50 50,#0.5 
33 55 66, 44 55 65 J]#1.0 
eventIn SFFloat set_fraction 


eventOut MFVec3f outValue 


In this case, there are 2 coordinates for every keyframe. The first 
two coordinates, (0, 0, 0) and (10, 10, 30), represent the value at 
keyframe 0.0; the second two coordinates, (10, 20, 10) and (40, 50, 50), 
represent that value at keyframe 0.5; and so on. If a set_fraction 
value of 0.25 (meaning 25% of the animation) was sent to this 
CoordinateInterpolator, the resulting output value would be: 


eventOut MFVec3f outValue [ 5 10 5, 25 30 40 ] 
Note: Given a sufficiently powerful scripting language, all of these 


interpolators could be implemented using Script nodes (browsers 
might choose to implement these as pre-defined prototypes of 
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appropriately defined Script nodes). Keyframed animation is 
common enough and performance intensive to justify the inclu- 
sion of these classes as built-in types. 


Lights and Lighting 


Objects are illuminated by the sum of all of the direct and indirect 
(ambient) illumination. Ambient illumination results from the 
scattering and reflection of light originally emitted by the light 
sources. Therefore, ambient light is associated with the lights in 
the scene, each having an ambientIntensity field. The contribution 
of a light to the overall ambient lighting is computed as 
ambientLight[i] = on ? (intensity * ambientIntensity * color[i]) : 0, 
i=0,1,2. This allows the light’s overall brightness, both direct and 
ambient, to be controlled by changing the intensity. Renderers that 
do not support per-light ambient illumination may simply use this 
information to set the ambient lighting parameters when the 
world is loaded. 


Sensor Nodes 


There are a variety of different kinds of sensors: ProximitySensor, 
TimeSensor, VisibilitySensor, and geometric sensors. 

The ProximitySensor detects when the user navigates into a 
specified invisible region in the world. The TimeSensor is a stop 
watch that has no geometry or location associated with it—it is 
used to start and stop time-based nodes, such as interpolators. The 
VisibilitySensor detects when a specific object in the world be- 
comes visible to the user and vice versa. 

Geometric sensor nodes detect user pointing events, such as the 
user clicking on a piece of geometry (i.e. TouchSensor). They exist 
in the local coordinate system determined by their place in the 
scene hierarchy. 
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Alphabetical Listing of Nodes 


Anchor 


The Anchor grouping node causes some data to be fetched over 
the network when any of its children are chosen. If the data 
pointed to isa VRML world, then that world is loaded and dis- 
played instead of the world of which the Anchor is a part. If 
another data type is fetched, it is up to the browser to determine 
how to handle that data; typically, it will be passed to an appropri- 
ate, already-open (or newly spawned) general Web browser. 

Exactly how a user “chooses” a child of the Anchor is up to the 
VRML browser; typically, clicking on one of its children with the 
mouse will result in the new scene replacing the current scene. An 
Anchor with an empty (“”) url does nothing when its children are 
chosen. 

The url is an arbitrary list of URLs. If multiple URLs are pre- 
sented, this expresses a descending order of preference. A browser 
may display a lower-preference URL if the higher-order file is not 
available. See the section on URLs and URNs. 

The description field in the Anchor allows for a friendly prompt 
to be displayed as an alternative to the URL in the url field. Ide- 
ally, browsers will allow the user to choose the description, the 
URL, or both to be displayed for a candidate Anchor. 

An Anchor may be used to take the viewer to a particular 
viewpoint in a virtual world by specifying a URL ending with 
“#viewpointName”, where “viewpointName” is the name of a 
viewpoint defined in the world. For example: 

Anchor { 

url "http://www.school.edu/vrml/someScene.wrl#0verView" 
children [ Box { } ] 

} 


specifies an anchor that puts the viewer in the “someScene” world 
looking from the viewpoint named “OverView” when the Box is 
chosen. If no world is specified, then the current scene is implied; 
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for example: 


Anchor { 

url "#Doorway" 

children [ Sphere { } ] 
} 


will take the viewer to the viewpoint defined by the “Doorway” 
viewpoint in the current world when the sphere is chosen. 


Anchor { 
field MFString url Eg 
field SFString description "" 


exposedField MFNode children [ ] 
} 


Prototype Definition 


PROTO Anchor [ 
field MFString url [ ] 
field SFString description "" 
exposedField MFNode children [ ] 
4 
Group { 
children [ 
DEF CS TouchSensor { }, 
Group { children IS children } 
] 
} 
DEF ASCRIPT Script { 
mustEvaluate TRUE 


field MFString name IS url 
eventIn SFBool loadWorld 
2 
# Script must load new world (using loadWorld() Script API) 
# when TouchSensor is clicked 
# 
} 
ROUTE CS.isActive TO ASCRIPT.1loadWorld 
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Appearance 


The Appearance node occurs only within the appearance field of a 
Shape node. The value for any of the fields in this node can be 
NULL. However, if the field contains anything, it must contain 
one specific type of node. Specifically, the material field, if speci- 
fied, must contain a Material node. The texture field, if specified, 
must contain one of the various Texture nodes (ImageTexture, 
MovieTexture, or PixelTexture). The textureTransform field, if 
specified, must contain a TextureTransform node. 


Appearance { 
exposedField SFNode material NULL 
exposedField SFNode texture NULL 


exposedField SFNode texturelransform NULL 
} 


AudioClip 


The AudioClip node represents a sound that is pre-loaded by the 
browser and can be started at any time and has a known duration. 
It can be used as the source for any VRML sound node. 

The url field specifies the URL from which the sound is loaded. 
The URL may contain sound data in any format for which there is 
a mime-type. However, for basic compatibility, browsers must 
support at least the wavefile format in uncompressed PCM for- 
mat. It is strongly recommended that browsers also support the 
MIDI file type 1 sound format. MIDI files are presumed to use the 
General MIDI patch set. Sounds should be loaded when the sound 
node is loaded. 

If multiple URLs are specified, then this expresses a descending 
order of preference. A browser may use a URL for a lower-prefer- 
ence file while it is obtaining, or if it is unable to obtain, the 
higher-preference file. (Also see the section on URNs.) Multiple 
URLs may also specify different sound formats so the browser 
should use the highest preference file that is in a format that it 
understands. 
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Browsers may limit the maximum number of sounds that can 
be played simultaneously and should use the guidelines specified 
with the Sound node to determine which sounds are actually 
played. 

The description field is a textual description of the sound, 
which may be displayed in addition to or in place of playing the 
sound. 

AudioClip nodes ignore changes to their startTime while they 
are actively outputting values. If a set_startTime event is received 
while the TimeSensor is active, then that set_startTime event is 
ignored (the startTime field is not changed, and a 
startTime_changed eventOut is NOT generated). A TimeSensor 
may be re-started while it is active by sending it a set_stopTime 
“now” event (which will cause the TimeSensor to become inac- 
tive) and then sending it a set_startTime event (setting it to “now” 
or any other starting time, in the future or past). 

The loop field specifies whether or not the sound is constantly 
repeated. By default, the sound is played only once. If the loop 
field is FALSE, the sound has length “length,” which is not speci- 
fied in the VRML file but is implicit in the sound file pointed to by 
the URL in the url field. If the loop field is TRUE, the sound has an 
infinite length. 

The startTime field specifies the time at which the sound should 
start playing. The stopTime field may be used to make a sound 
stop playing some time after it has started. 

The pitch field specifies a multiplier for the rate at which 
sampled sound is played. Changing the pitch field affects the 
pitch of a sound. If pitch is set to 2.0, the sound should be played 
one octave higher than normal which corresponds playing it twice 
as fast. The proper implementation of the pitch control for MIDI 
(or other note sequence sound clip) is to multiply the tempo of the 
playback by the pitch value and adjust the MIDI Coarse Tune and 
Fine Tune controls to achieve the proper pitch change. 

The duration eventOut field is sent out whenever there is a new 
value for the “normal” duration of the clip. Typically this will only 
occur when the url field is changed, indicating that the clip is 
playing a different sound source. The duration is the length of 
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time in seconds that the sound will play when the pitch is set to 
1.0. Changing the pitch field should not trigger the duration event. 
The isActive field can be used by other nodes to determine if 
the clip is currently being played (or at least in contention to be 
played) by a sound node. The following algorithm expresses the 
conditions that should affect when isActive is TRUE and when it 
is FALSE. 
With the current time now, and the duration of the sound as 
length the rules are as follows: 
if (now < startTime) 
isActive = FALSE 
else if (now >= startTime+length) 
isActive = FALSE ) 
else if (stopTime > startTime) && (startTime <= now < 
stopTime) 
isActive = TRUE 
else isActive = TRUE 


Whenever startTime, stopTime, or now changes, the above rules 
need to be applied to figure out if the sound is playing. If it is, 
then it should be playing the bit of sound at (now - startTime) or, if 
it is looping, fmod(now - startTime, realLength). 

If a set_startTime event is received while the TimeSensor is 
active, then that set_startTime event is ignored (the startTime field 
is not changed, and a startTime_changed eventOut is NOT gener- 
ated). A TimeSensor may be re-started while it is active by sending 
it'a set_stopTime “now” event (which will cause the TimeSensor to 
become inactive) and then sending it a set_startTime event (setting 
it to “now” or any other starting time, in the future or past). 


AudioClip { 


field MFString url [ ] 
field SFString description "" 
exposedField SFBool loop FALSE 


exposedField SFlime startTime 0 
exposedField SFTime  stopTime 0 
exposedField SFFloat pitch 1.0 
eventOut SFTime duration 0 
eventOut SFBool isActive FALSE 
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Background 


The Background node is used to specify a color-ramp backdrop 
that simulates ground and sky planes, as well as an environment 
texture, or panorama, that is placed behind all geometry in the 
scene and in front of the backdrop. 

The background is not affected by translations or scales in the 
hierarchy. Rotations do affect the background as any other geo- 
metric object. 

The backdrop is conceptually a sphere with an infinite radius, 
painted with a smooth gradation of ground colors (starting with a 
circle straight downward and rising in concentric bands up to the 
horizon) and a separate gradation of sky colors (starting with a 
circle straight upward and falling in concentric bands down to the 
horizon). (It’s acceptable to implement the backdrop as a cube 
painted in concentric square rings instead of as a sphere.) The 
groundRanges field is a list of floating point values that indicate 
the cutoff for each groundColor. Its implicit initial value is 0 
radians (downward), and the final value given indicates the 
elevation angle of the horizon, where the ground color ramp and 
the sky color ramp meet. The skyRanges field implicitly starts at 0 
radians (upward) and works its way down to pi radians. If 
groundColors is NULL, no ground colors are used. 

The pos/neg/X/Y/Z fields define a background panorama, 
between the backdrop and the world’s geometry. The panorama 
consists of a six images, each of which is mapped onto the faces of 
a cube surrounding the world. Transparency values in the pan- 
orama images specify that the panorama is transparent in particu- 
lar places, allowing the groundColors and skyColors to show 
through. (Often, the posY and negY images will not be specified, 
to allow sky and ground to show. The other four images may 
depict mountains or other distant scenery.) By default, there is no 
panorama. , 

The first Background node found during reading of the world is 
used as the initial background. Subsequent Background nodes are 
ignored. The current background may be changed by Script node 
API calls. 
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Ground colors, sky colors, and panoramic images do not trans- 
late with respect to the viewer, though they do rotate with respect 
to the viewer. That is, the viewer can never get any closer to the 
background, but can turn to examine all sides of the panorama 
cube, and can look up and down to see the concentric rings of 
ground and sky (if visible). 


Background { 
exposedfield MFColor groundColor [ 0.14 0.28 0.00, 

# light green 

0.09 0.11 0.00 J 

# to dark green 
exposedField MFFloat groundRange [ .785 ] 

# horizon = 45 degrees 
exposedField MFColor § skyColor [ 0.02 0.00 0.26, 

# twilight blue 

0.02 0.00 0.65 ] 

# to light blue 
exposedField MFFloat skyRange [ .785 ] 

# horizon = 45 degrees 
exposedField MFString posX 
exposedField MFString negX 
exposedField MFString posY 
exposedField MFString negY 
exposedField MFString posZ 
exposedField MFString negZ 
eventIn SFBool bind 
eventOut SFBool isBound 


| camo TO ma a cco IR eae He oe | 
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Billboard 


The billboard node is a grouping node which modifies its coordi- 
nate system so that the billboard node’s local z-axis turns to point 
at the camera. The billboard node has children which may be 
other grouping or leaf nodes. This allows you to billboard any 
geometry. 

The axisOfRotation field specifies which axis to use to perform 
the rotation. This axis is defined in the local coordinates of the 
billboard node. The default (0,1,0) is useful for objects such as 
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images of trees and lamps positioned on a ground plane. But 
when an object is oriented at an angle, for example, on the incline 
of a mountain, then the axisOfRotation may also need to be 
oriented at a similar angle. 

A special case of billboarding is screen-alignment—the object 
rotates to always stay aligned with the camera even when the 
camera elevates, pitches and rolls. This special case is distin- 
guished by setting the axisOfRotation to (0, 0, 0). 

To rotate the billboard to face the camera, you determine the 
line between the billboard’s origin and the camera’s origin; call 
this the billboard-to-camera line. The axisOfRotation and the 
billboard-to-camera line define a plane. The local z-axis of the 
billboard is then rotated into that plane, pivoting around the 
axisOfRotation. 

If the axisOfRotation and the billboard-to-camera line are 
coincident (the same line), then the plane cannot be established, 
and the rotation results of the billboard are undefined. For ex- 
ample, if the axisOfRotation is set to (0,1,0) (the y-axis) and the 
camera flies over the object, then the object will spin as the camera 
passes directly over the y-axis. It is undefined at the pole. Another 
example of this ill-defined behavior occurs when the author sets 
the axisOfRotation to (0,0,1) (the z-axis) and sets the camera to 
look directly down the z-axis of the object. 

Billboard { 

exposedField MFNode children NULL 
exposedField SFVec3f axisOfRotation 010 
} 


Prototype definition: 


Billboard [ 
exposedField MFNode children NULL 
exposedField SFVec3f axisOfRotation 010 
1 { 
TBD ... [Transform plus Script node] 
} 
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Box 


This node represents a rectangular aligned with the coordinate 
axes. By default, the box is centered at (0,0,0) and measures 2 units 
in each dimension, from —1 to +1. A box’s width is its extent along 
its object-space X axis, its height is its extent along the object-space 
Y axis, and its depth is its extent along its object-space Z axis. 

Textures are applied individually to each face of the box; the 
entire texture goes on each face. On the front, back, right, and left 
sides of the box, the texture is applied right side up. On the top, 
the texture appears right side up when the top of the box is tilted 
toward the user. On the bottom, the texture appears right side up 
when the top of the box is tilted towards the -Z axis. 

Box { 

field sPVecST size 2.2 2 
} 


[PROTO - TBD] 


Collision 


_ The Collision grouping node specifies to a browser what objects in 
the scene should not be navigated through. It is useful to keep 
viewers from walking through walls in a building, for instance. 
Collision response is browser-defined. For example, when the user 
comes sufficiently close to an object to register as a collision, the 
browser may have the user bounce off the object or simply come 
to a stop. 

The children of a Collision node are always drawn, just as the 
children of a simple Group are drawn. These children are the 
objects that are checked for collision. If desired, a proxy can be 
supplied, and this proxy will be checked for collision in place of 
the actual child objects (see description of the proxy field, below). 

By default, collision detection is ON. The collide field in this 
node allows collision detection to be turned off, in which case the 
children of the Collision node will not be checked for collision, 
even though they will be drawn. 
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Since collision with arbitrarily complex geometry is 
computationally expensive, one method of increasing efficiency is 
to be able to define an alternate geometry that could serve as a 
proxy for colliding against. This collision proxy, contained in the 
proxy field, could be as crude as a simple bounding box or bound- 
ing sphere, or could be more sophisticated (for example, the 
convex hull of a polyhedron). The proxy field should contain a 
grouping or leaf node. 

If the value of the collide field is FALSE, then no collision is 
performed with the affected geometry. If the value of the collide 
field is TRUE, then the proxy field defines the geometry against 
which collision testing is done. If the proxy value is NULL, the 
children of the collision node are collided against. If the proxy 
value is not NULL, then it contains the geometry that is used in 
collision computations. 

If children is empty, collide is TRUE and a proxy is specified 
then collision detection is done against the proxy but nothing is 
displayed—this is a way of colliding against “invisible” geometry. 

The collision eventOut will generate an event containing the 
time when the path of the user through the scene intersects a 
geometry in this collision node against which collisions are being 
checked. An ideal implementation would compute the exact 
moment of intersection, but implementations may approximate 
the ideal by sampling the positions of geometries and the viewer. 
Refer to the NavigationInfo node for parameters that control the 
user’s size. 


Collision { 
exposedField SFBool collide TRUE 
field SFNode proxy NULL 


exposedField MFNode children [] 
eventOut SFTime collision 
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This node defines a set of RGB colors to be used in the color fields 
of an IndexedFaceSet, IndexedLineSet, or PointSet node. 

Color nodes are only used to specify multiple colors for a single 
piece of geometry, such as a different color for each face or vertex 
of an IndexedFaceSet. A Material node is used to specify the 
overall material parameters of a lighted geometry. If both a Mate- 
rial and a Color node are specified for a geometry, the colors 
should ideally replace the diffuse component of the material. 

Textures take precedence over colors; specifying both a Texture 
and a Color node for a geometry will result in the Color node 
being ignored. 

Note: Some browsers may not support this functionality, in 
which case an average, overall color should be computed and 
used instead of specifying colors per vertex. 

Color { 


exposedField MFColor rgb [] 
} 


Colorinterpolator 
aS ee ee 


ss 


This node interpolates among a set of MFColor values, to produce 
an SFColor outValue event. The number of colors in the values 
field must be equal to the number of keyframe times in the keys 
field. The color values are linearly interpolated in RGB space. 


ColorInterpolator { 


exposedField MFFloat keys [] 
exposedField MFColor values ‘eS 
eventIn SFFloat set_fraction 


eventOut SFColor outValue 
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Example file syntax interpolates from red to green to blue ina 
10 second cycle: 


DEF myColor ColorInterpolator { 
MFFloat keys Lp ? 202 0.5, 1.0 ] 
<Computer Co MFColor values E200. 0 28. 2°02 J 
# red, green, blue 
} 
DEF myClock TimeSensor { 
cycleInterval 10.0 # 10 second animation 
loop TRUE # infinitely cycling animation 
} 
ROUTE myClock.fraction TO myColor.set_fraction 


Prototype Definition 


PROTO ColorInterpolator [ 
exposedField MFFloat keys [] 
exposedField MFColor values [J 
eventIn SFFloat set_fraction 
eventOut SFColor outValue 
1 { 
Script { 
exposedField MFFloat keys IS keys 
exposedField MFColor values IS values 


eventIn SFFloat set_fraction IS set_fraction 
eventOut MFColor outValue IS outValue 
# 
# Does the math to map input fraction into values based 
# on keys... . 
} 
} 
Coordinate 


This node defines a set of 3D coordinates to be used in the coord 
field of vertex-based geometry nodes (such as IndexedFaceSet, 
IndexedLineSet, and PointSet). 

Coordinate { 


exposedField MFVec3f point [] 
} 
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Cone 


This node represents a simple cone whose central axis is aligned 
with the Y axis. By default, the cone is centered at (0,0,0) and has a 
size of —1 to +1 in all three directions. The cone has a radius of 1 at 
the bottom and a height of 2, with its apex at 1 and its bottom at -1. 

The cone has two parts: the side and the bottom. Each part has 
an associated SFBool field that specifies whether it is visible 
(TRUE) or invisible (FALSE). 

When a texture is applied to a cone, it is applied differently to 
the sides and bottom. On the sides, the texture wraps counter- 
clockwise (from above) starting at the back of the cone. The tex- 
ture has a vertical seam at the back, intersecting the YZ plane. For 
the bottom, a circle is cut out of the texture square and applied to 
the cone’s base circle. The texture appears right side up when the 
top of the cone is rotated towards the —Z axis. 


Cone { 
field SFFloat  bottomRadius 1 
field SFFloat height 2 
field SFBool side TRUE 
field SFBool bottom TRUE 


} 


Coordinatelnterpolator 


This node linearly interpolates among a set of MFVec3f values. 
This would be appropriate for interpolating vertex positions for a 
geometric morph. 

The number of coordinates in the values field must be an 
integer multiple of the number of keyframe times in the keys field; 
that integer multiple defines how many coordinates will be con- 
tained in the outValue events. 


CoordinateInterpolator { 


exposedField MFFloat keys [J 
exposedField MFVec3f values [J 
eventIn SFFloat set_fraction 


eventOut MFVec3f outValue 
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Prototype Definition 
PROTO CoordinateInterpolator [ 
exposedField MFFloat keys [] 
exposedField MFVec3f values [J 
eventIn SFFloat set_fraction 


eventOut MFVec3f outValue 


1 | 
Script { 
exposedField MFFloat keys IS keys 
exposedField MFVec3f values IS values 
eventIn SFFloat set_fraction IS set_fraction 
eventOut MFVec3f outValue IS outValue 
= 
# Does the math to map input fraction into values based 
on keys... 
} 
} 
Cylinder 


This node represents a simple capped cylinder centered around 
the Y axis. By default, the cylinder is centered at (0,0,0) and has a 
default size of —1 to +1 in all three dimensions. You can use the 
radius and height fields to create a cylinder with a different size. 

The cylinder has three parts: the side, the top (Y = +1) and the 
bottom (Y = -1). Each part has an associated SFBool field that 
indicates whether the part is visible (TRUE) or invisible (FALSE). 

When a texture is applied to a cylinder, it is applied differently 
to the sides, top, and bottom. On the sides, the texture wraps 
counterclockwise (from above) starting at the back of the cylinder. 
The texture has a vertical seam at the back, intersecting the YZ 
plane. For the top and bottom, a circle is cut out of the texture 
square and applied to the top or bottom circle. The top texture 
appears right side up when the top of the cylinder is tilted toward 
the +Z axis, and the bottom texture appears right side up when 
the top of the cylinder is tilted toward the —Z axis. 
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Cylinder { 
field SFFloat radius 1 
field SFFloat height 2 
field SFBoo] side TRUE 
field SFBool top TRUE 
field SFBool] bottom TRUE 


CylinderSensor 


The CylinderSensor maps pointer device (e.g. mouse or wand) 
dragging motion into a rotation around the Y axis of its local 
space. As the other touch sensors (DiscSensor, PlaneSensor, 
SphereSensor, TouchSensor), CylinderSensor uses all of the geom- 
etry contained by its parent node to determine if a hit occurs. 

minAngle and maxAngle may be set to clamp rotation events to 
a range of values (measured in radians about the local Y axis). If 
minAngle is greater than maxAngle, rotation events are not 
clamped. 

Upon the initial click down on the CylinderSensor’s geometry, 
the specific point clicked determines the radius of the cylinder 
used to map pointing device motion while dragging. trackPoint 
events always reflect the unclamped drag position on the surface 
of this cylinder, or in the plane perpendicular to the view vector if 
the cursor moves off this cylinder. An onCylinder TRUE event is 
generated at the initial click down; thereafter, onCylinder FALSE/ 
TRUE events are generated if the pointing device is dragged off/ 
on the cylinder. 

CylinderSensor { 

exposedField SFFloat minAngle 0 


exposedField SFFloat maxAngle 0 
exposedField SFBool enabled TRUE 


eventOut SFBool isActive 
event0Out SFVec3f trackPoint 
eventOut SFRotation rotation 


eventOut SFBool onCylinder 
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DirectionalLight 


The DirectionalLight node defines a directional light source that 
illuminates along rays parallel to a given 3-dimensional vector. 
See Lights and Lighting for an explanation of ambient lighting. 

A directional light source illuminates only the objects in its 
enclosing Group. The light illuminates everything within this 
coordinate system, including the objects that precede it in the 
scene graph—for example: 


Transform { 


children [ 

Shape { ... }, 

DirectionalLight { .... } # lights the preceding shape 
] 


Some low-end renderers do not support the concept of per- 
object lighting. This means that placing DirectionalLights inside 
local coordinate systems, which implies lighting only the objects 
beneath the Transform with that light, is not supported in all 
systems. For the broadest compatibility, lights should be placed at 
outermost scope. 

DirectionalLight { 

exposedField SFBool on TRUE 

exposedField SFFloat intensity 
exposedField SFFloat ambientIntensity 
exposedField SFColor color 
exposedField SFVec3f direction 


DiskSensor 


The DiskSensor maps dragging motion into a rotation around the 
Z axis of its local space. The feel of the rotation is as if you were 
scratching on a record turntable. 
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minAngle and maxAngle may be set to clamp rotation events to 
a range of values as measured in radians about the Z axis. If 
minAngle is greater than maxAngle, rotation events are not 
clamped. trackPoint events provide unclamped drag position in 
the XY plane. 
DiskSensor { 
exposedField SFFloat minAngle 0 
exposedField SFFloat maxAngle 0 
exposedField SFBool enabled TRUE 


eventOut SFBool isActive 
eventOut SFVec3f trackPoint 
eventOut SFRotation rotation 
} 
ElevationGrid 


This node creates a rectangular grid of varying height, especially 
useful in modeling terrain. The model is primarily described by a 
scalar array of height values that specify the height of the surface 
above each point of the grid. 

The verticesPerRow and verticesPerColumn fields indicate the 
number of grid points in the X and Z directions, respectively, 
defining a grid of (verticesPerRow-1) x (verticesPerColumn-1) 
rectangles. (Note that the number of columns of vertices is defined 
by verticesPerRow and the number of rows of vertices is defined 
by verticesPerColumn. Rows are numbered from 0 through 
verticesPerColumn-1; columns are numbered from 0 through 
verticesPerRow-1.) 

The vertex locations for the rectangles are defined by the height 
field and the gridStep field: The height field is an array of scalar 
values representing the height above the grid for each vertex. The 
height values are stored so that row 0 is first, followed by rows 1, 
2, ... verticesPerColumn-1. Within each row, the height values are 
stored so that column 0 is first, followed by columns 1, 2, ... 
verticesPerRow-1. The gridStep field contains two values in the 
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form of an SFVec2f field: gridStep[0] indicates the distance be- 
tween columns, and gridStep[1] indicates the distance between 
rows. Thus, the vertex corresponding to the ith row and jth col- 
umn is placed at 

( gridStep[0] * j, heights[ ixverticesPerRow + j J, gridStepL 

Lei} 
in object space, where 0 <= i < verticesPerColumn, and 0 <=j < 
verticesPerRow. 

All points in a given row have the same Z value, with row 0 
having the smallest Z value. All points in a given column have the 
same X value, with column 0 having the smallest X value. 

The default texture coordinates range from [0,0] at the first 
vertex to [1,1] at the far side of the diagonal. The S texture coordi- 
nate will be aligned with X, and the T texture coordinate with Z. 

The colorPerVertex field determines whether colors (if specified 
in the color field) should be applied to each vertex or each quadri- 
lateral of the ElevationGrid. If colorPerVertex is FALSE and the 
color field is not NULL, then the color field must contain a Color 
node containing at least (verticesPerColumn-1)*(verticesPerRow-1) 
colors. If colorPerVertex is TRUE and the color field is not NULL, 
then the color field must contain a Color node containing at least 
verticesPerColumn*verticesPerRow colors. 

See the introductory Geometry section for a description of the 
ccw, solid, and creaseAngle fields. 

By default, the rectangles are defined with a counterclockwise 
ordering, so the Y component of the normal is positive. Setting the 
ccew field to FALSE reverses the normal direction. Backface culling 
is enabled when the ccw field and the solid field are both TRUE 


(the default). 
ElevationGrid { 

field SFInt32 verticesPerColumn 0 
field SFInt32 verticesPerRow 0 
field SFVec2f gridStep oe 
field MFFloat height [ ] 
exposedField SFNode color NULL 
field SFBool colorPerVertex TRUE 
exposedField SFNode = normal NULL 


field SFBool normalPerVertex TRUE 
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exposedField SFNode  texCoord NULL 
field SFBool CCW TRUE 
field SFBool solid TRUE 
field SFFloat creaseAngle 0 
} 
Extrusion 


The Extrusion node is used to define shapes based on a two 
dimensional cross section extruded along a three dimensional 
spine. The cross section can be scaled and rotated at each spine 
point to produce a wide variety of shapes. 

An Extrusion is defined by a 2D crossSection piecewise linear 
curve (described as a series of connected vertices), a 3D spine 
piecewise linear curve (also described as a series of connected 
vertices), a list of 2D scale parameters, and a list of 3D orientation 
parameters. Shapes are constructed as follows: The cross-section 
curve, which starts as a curve in the XZ plane, is first scaled about 
the origin by the first scale parameter (first value scales in X, 
second value scales in Z). It is then rotated about the origin by the 
first orientation parameter, and translated by the vector given as 
the first vertex of the spine curve. It is then extruded through 
space along the first segment of the spine curve. Next, it is scaled 
and rotated by the second scale and orientation parameters and 
extruded by the second segment of the spine, and so on. 

A transformed cross section is found for each joint (that is, at 
each vertex of the spine curve, where segments of the extrusion 
connect), and the joints and segments are connected to form the 
surface. No check is made for self-penetration. Each transformed 
cross section is determined as follows: 


1. Start with the cross section as specified, in the XZ plane. 

2. Scale it about (0, 0, 0) by the value for scale given for the 
current joint. 

3. Apply a rotation so that when the cross section is placed at its 
proper location on the spine it will be oriented properly. 
Essentially, this means that the cross section’s Y axis (up vector 
coming out of the cross section) is rotated to align with an 
approximate tangent to the spine curve. 
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For all points other than the first or last: The tangent for 
spine|i] is found by normalizing the vector defined by 
(spine[i+1] — spine[i—1)). 

If the spine curve is closed: The first and last points need to 
have the same tangent. This tangent is found as above, but 
using the points spine[0] for spine[i], spine[1] for spine[i+1] 
and spine[n-2] for spine[i-1], where spine[n—2] is the next to 
last point on the curve. The last point in the curve, spine[n—1], 
is the same as the first, spine[0]. 

If the spine curve is not closed: The tangent used for the first 
point is just the direction from spine[0] to spine[1], and the 
tangent used for the last is the direction from spine[n-2] to 
spine[n-1]. 

In the simple case where the spine curve is flat in the XY 
plane, these rotations are all just rotations about the Z axis. In 
the more general case where the spine curve is any 3D curve, 
you need to find the destinations for all 3 of the local X, Y, and 
Z axes so you can completely specify the rotation. The Z axis is 
found by taking the cross product of 


(spineLi-l1] - spineli]) and (spine[i+1l] - spine[i]). 


If the three points are collinear then this value is zero, so 
take the value from the previous point. Once you have the Z 
axis (from the cross product) and the Y axis (from the approxi- 
mate tangent), calculate the X axis as the cross product of the Y 
and Z axes. 


4. Given the plane computed in step 3, apply the orientation to 
the cross-section relative to this new plane. Rotate it counter- 
clockwise about the axis and by the angle specified in the 
orientation field at that joint. 

5. Finally, the cross section is translated to the location of the 
spine point. 


Surfaces of revolution: If the cross section is an approxima- 
tion of a circle and the spine is straight, then the Extrusion 
is equivalent to a surface of revolution, where the scale 
parameters define the size of the cross section along the 
spine. 
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© Cookie-cutter extrusions: If the scale is 1, 1 and the spine is 
straight, then the cross section acts like a cookie cutter, with 
the thickness of the cookie equal to the length of the spine. 


Y 


Bend/twist/taper objects: These shapes are the result of 
using all fields. The spine curve bends the extruded shape 
defined by the cross section, the orientation parameters 
twist it around the spine, and the scale parameters taper it 
(by scaling about the spine). 


Extrusion has three parts: the sides, the beginCap (the surface at 
the initial end of the spine) and the endCap (the surface at the 
final end of the spine). The caps have an associated SFBool field 
that indicates whether it exists (TRUE) or doesn’t exist (FALSE). 

When the beginCap or endCap fields are specified as TRUE, 
planar cap surfaces will be generated regardless of whether the 
crossSection is a closed curve. (If crossSection isn’t a closed curve, 
the caps are generated as if it were—equivalent to adding a final 
point to crossSection that’s equal to the initial point. Note that an 
open surface can still have a cap, resulting (for a simple case) in a 
shape something like a soda can sliced in half vertically.) These 
surfaces are generated even if spine is also a closed curve. If a field 
value is FALSE, the corresponding cap is not generated. 

Extrusion automatically generates its own normals. Orientation 
of the normals is determined by the vertex ordering of the tri- 
angles generated by Extrusion. The vertex ordering is in turn 
determined by the crossSection curve. If the crossSection is drawn 
counterclockwise, then the polygons will have counterclockwise 
ordering when viewed from the ‘outside’ of the shape (and vice 
versa for clockwise ordered crossSection curves). 

Texture coordinates are automatically generated by extrusions. 
Textures are mapped like the label on a soup can: the coordinates 
range in the U direction from 0 to 1 along the crossSection curve 
(with 0 corresponding to the first point in crossSection and 1 to the 
last) and in the V direction from 0 to 1 along the spine curve 
(again with 0 corresponding to the first listed spine point and 1 to 
the last). When crossSection is closed, the texture has a seam that 
follows the line traced by the crossSection’s start/end point as it 
travels along the spine. If the endCap and/or beginCap exist, the 
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crossSection curve is cut out of the texture square and applied to the 
endCap and/or beginCap planar surfaces. The beginCap and endCap 
textures’ U and V directions correspond to the X and Z directions in 
which the crossSection coordinates are defined. 

See the introductory Geometry section for a description of the ccw, 
solid, convex, and creaseAngle fields. 


Extrusion { 

field MFVec3f 
eventIn MFVec3f 
field MFVec2f 
eventIn MFVec2f 
field MFVec2f 
eventiIn MFVec2f 
field MFRotation 
eventIn MFRotation 
field SFBool 
field SFBool 
field  SFBool 
field  SFBool 
field  SFBool 
field  SFFloat 


Prototype Definition 


PROTO Extrusion [ 
field MFVec3f 
eventIn MFVec3f 
field MFVec2f 
eventIn MFVec2f 
field MFVec2f 
eventIn MFVec2f 
field MFRotation 
eventIn MFRotation 
field SFBool 
field  SFBool 
field  SFBool 
field  SFBool 
field  SFBool 
field  SFFloat 


spine [000,010] 

set_spine 

crossSection [ 1 1, -1 1,.-1 -1, 1-1, 11 ] 
set_crossSection 


scale [ ] 
set_scale 

orientation [ ] 
set_orientation 
beginCap TRUE 
endCap TRUE 
CCW TRUE 
solid TRUE 
convex TRUE 
creaseAngle 0 
spine [000,010] 
set_spine 


crossSection [ 11, -1 1, -1 -1, 1-1, 11 ] 
set_crossSection 


scale [ ] 
set_scale 

orientation [ ] 
set_orientation 
beginCap TRUE 
endCap TRUE 
CCW TRUE 
solid TRUE 
convex TRUE 


creaseAngle 0 
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SS SS 


] { 
DEF IFS IndexedFaceSet 


{ 


coord DEF C Coordinate 


ccw IS ccw 
solid IS solid 
convex IS convex 


creaseAngle IS creaseAngle 


DEF S Script { 
field MFVec3f 
eventIn MFVec3f 
field MFVec2f 
eventIn MFVec2f 


field MFVec2f 
eventIn MFVec2f 
field MFRotation 
eventIn MFRotation 
field SFBool 
field SFBool 


spine IS spine 

set_spine IS set_spine 
crossSection IS crossSection 
set_crossSection IS 
set_crossSection 

scale IS scale 

set_scale IS set_scale 
orientation IS orientation 
set_orientation IS set_orientation 
beginCap IS beginCap 

endCap IS endCap 


eventOut MFVec3f coord 
eventOut MFInt32 coordIndex 


behavior "Extrusion. java" 


} 


ROUTE S.coord TO C.set_ 


point 


ROUTE S.coordIndex TO IFS.set_coordIndex 


The Fog node defines an axis-aligned ellipsoid of colored atmo- 
sphere. The size field defines the x, y, and z radii of the foggy 
ellipsoid in the local coordinate system. The visibilityRange field 
specifies the distance at which an object is completely obscured by 
the fog. This distance is specified in the local coordinate system 
(by default, in meters). This distance assumes that the viewer and 
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object are contained within the fog ellipsoid. For regions outside 
the fog and where partial fog coverage occurs, the color field may 
be used to simulate different kinds of atmospheric effects by 
changing the fog’s color. For example, a fog color of (1,1,1) pro- 
duces a hazy atmosphere, while a fog color of (0,0,0) creates a 
depth cueing effect. To produce a realistic fog appearance, the Fog 
node would be used in combination with a Background node with 
skyColor equivalent to the fog color. 

An ideal implementation of fog would compute exactly how 
much attenuation occurs between the viewer and each object in 
the world and render the scene appropriately. However, imple- 
mentations are free to approximate this ideal behavior, perhaps by 
computing the intersection of the viewing direction vector with 
any foggy regions and computing overall fogging parameters each 
time the scene is rendered. Assume exponential falloff. 


Fog { 
exposedField SFVec3f size 000 
exposedField SFFloat visibilityRange 1 
exposedField SFColor color Lad 
} 
FontStyle 


The FontStyle node, which may only appear in the fontStyle field 
of a Text node, defines the size, font family, and style of the text 
font, as well as the direction of the text strings and any specific 
language rendering techniques that must be used for non-English 
text. 

The size field specifies the height (in object space units) of 
glyphs rendered and determines the spacing of adjacent lines of 
text depended on the direction field. All subsequent strings ad- 
vance in either x or y by -( size * spacing). (See the Text node for a 
description of the spacing field.) 
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Font Family and Style 

Font attributes are defined with the family and style fields. It is up 
to the browser to assign specific fonts to the various attribute 
combinations. 

The family field contains an SFString value that can be “SERIF” 
(the default) for a serif font such as Times Roman; “SANS” for a 
sans-serif font such as Helvetica; or “TYPEWRITER” for a fixed- 
pitch font such as Courier. 

The style field contains an SFString value that can be an empty 
string (the default); “BOLD” for boldface type; “ITALIC” for italic 
type; or “BOLD ITALIC” for bold and italic type. 


Direction, Justification and Spacing 


The horizontal, leftToRight, and topToBottom fields indicate the 
direction of the text. The horizontal field indicates whether the 
text is horizontal (specified as TRUE, the default) or vertical 
(FALSE). The leftToRight field indicates whether the text 
progresses from left to right (specified as TRUE, the default) or 
from right to left (FALSE). The topToBottom field indicates 
whether the text progresses from top to bottom (specified as 
TRUE, the default), or from bottom to top (FALSE). 

The justify field determines where the text is positioned in 
relation to the origin (0,0,0) of the object coordinate system. The 
values for the justify field are “BEGIN”, “MIDDLE”, and “END”. 
For a left-to-right direction, “BEGIN” would specify left-justified 
text, “END” would specify right-justified text, and “MIDDLE” 
would specify centered text. See the FontStyle node for details of 
text placement. 

The spacing field determines the spacing between multiple text 
strings. 

The size field of the FontStyle node specifies the height (in 
object space units) of glyphs rendered and determines the vertical 
spacing of adjacent lines of text. All subsequent strings advance in 
either X or Y by —(size * spacing). A value of 0 for spacing causes 
the string to be in the same position. A value of —1 causes subse- 
quent strings to advance in the opposite direction. 
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For horizontal text (horizontal = TRUE), the first line of text is 
positioned with its baseline (bottom of capital letters) at Y = 0. The 
text is positioned on the positive side of the X origin when 
leftToRight is TRUE and justify is “BEGIN”; the same positioning 
is used when leftToRight is FALSE and justify is “END”. The text 
is on the negative side of the X origin when leftToRight is TRUE 
and justify is “END” (and when leftToRight is FALSE and justify is 
“BEGIN”). For justify = “MIDDLE” and horizontal = TRUE, each 
string will be centered at X = 0. 

For vertical text (horizontal is FALSE), the first line of text is 
positioned with the left side of the glyphs along the Y axis. When 
topToBottom is TRUE and justify is “BEGIN” (or when 
topToBottom is FALSE and justify is “END”), the text is positioned 
with the top left corner at the origin. When topToBottom is TRUE 
and justify is “END” (or when topToBottom is FALSE and justify 
is “BEGIN”), the bottom left is at the origin. For justify = 
“MIDDLE” and horizontal = FALSE, the text is centered vertically 
at X = 0. 

The language field specifies the context of the language for the 
text string. Due to the multilingual nature of the I5010646-1:1993, 
the language field is needed to provide a proper language at- 
tribute of the text string. The format is based on the POSIX locale 
specification as well as the RFC 1766: language[_territory]. The 
values for the language tag are based on the ISO 6339, i.e. zh for 
Chinese, jp for Japanese, sc for Swedish. The territory tag is based 
on the ISO 3166 country code, i.e. TW is for Taiwan and CN for 
China for the “zh” Chinese language tag. 

Please refer to these sites for more details: 

http://www.chemie. fu-berlin.de/diverse/doc/1S0_639.html 
http://www.chemie. fu-berlin.de/diverse/doc/IS0_3166.htm1 


FontStyle { 
field SFFloat size 1.0 
field SFString family "SERIF" # "SERIF", "SANS", "TYPEWRITER" 
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field SFString style "" # "BOLD", "ITALIC", "BOLD ITALIC" 
field SFBool horizontal TRUE 

field SFBool leftToRight TRUE 

field SFBool topToBottom TRUE 

field SFString language = 

field SFString justify "BEGIN" # "BEGIN", "MIDDLE", "END" 
field SFFloat spacing 1.0 


A Group node is a lightweight grouping node that can contain any 
number of children. It is equivalent to a Transform node, without 
the transformation fields. 


Group { 
field SFVec3f bboxCenter 0 0 0 
field SFVec3f bboxSize 000 
exposedField MFNode children [ ] 
eventIn MFNode add_children 
eventIn MFNode remove_children 

} 

Prototype Definition 

PROTO Group [ 
field SFVec3f bboxCenter 0 0 0 
field SFVec3f bboxSize 000 
exposedField MFNode_ children [ ] 
eventIn MFNode add_children 
eventIn MFNode remove_children 

4 


Transform { 
bboxCenter IS bboxCenter 
bboxSize IS bboxSize 
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children IS children 
add_children IS add_children 
remove_children IS remove_children 
} 
} 


Image Texture 


The ImageTexture node defines a texture map and parameters for 
that map. 

The texture is read from the URL specified by the url field. To 
turn off texturing, set the url field to have no values ([]). Imple- 
mentations should support the JPEG and PNG image file formats. 
Support for the GIF format is also recommended. 

Texture images may be one component (greyscale), two compo- 
nent (greyscale plus transparency), three component (full RGB 
color), or four-component (full RGB color plus transparency). An 
ideal VRML implementation will use the texture image to modify 
the diffuse color and transparency of an object’s material (speci- 
fied in a Material node), then perform any lighting calculations 
using the rest of the object’s material properties with the modified 
diffuse color to produce the final image. 

The texture image modifies the diffuse color and transparency 
depending on how many components are in the image, as follows: 


1. Diffuse color is multiplied by the greyscale values in the 
texture image. 

2. Diffuse color is multiplied by the greyscale values in the 
texture image; material transparency is multiplied by transpar- 
ency values in texture image. 

3. RGB colors in the texture image replace the material’s diffuse 
color. 

4. RGB colors in the texture image replace the material’s diffuse 
color; transparency values in the texture image replace the 
material’s transparency. 
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Browsers may approximate this ideal behavior to increase 
performance. One common optimization is to calculate lighting 
only at each vertex and combining the texture image with the 
color computed from lighting (performing the texturing after 
lighting). Another common optimization is to perform no lighting 
calculations at all when texturing is enabled, displaying only the 
colors of the texture image. 

The repeatS and repeatT fields specify how the texture wraps in 
the S and T directions. If repeatS is TRUE (the default), the texture 
map is repeated outside the 0-to-1 texture coordinate range in the 
S direction so that it fills the shape. If repeatS is FALSE, the texture 
coordinates are clamped in the S direction to lie within the 0-to-1 
range. The repeatT field is analogous to the repeatS field. 


ImageTexture { 
exposedField MFString url [ ] 
field SFBool repeatS TRUE 
field SFBool repeatT TRUE 
} 
IndexedFaceSet 


The IndexedFaceSet node represents a 3D shape formed by con- 
structing faces (polygons) from vertices listed in the coord field. 
The coord field must contain a Coordinate node. IndexedFaceSet 
uses the indices in its coordIndex field to specify the polygonal 
faces. An index of —1 indicates that the current face has ended and 
the next one begins. The last face may (but does not have to be) 
followed by a -1. If the greatest index in the coordIndex field is N, 
then the Coordinate node must contain N+1 coordinates (indexed 
as 0-N). 

For descriptions of the coord, normal, and texCoord fields, see 
the Coordinate, Normal, and TextureCoordinate nodes. 

If the color field is not NULL then it must contain a Color node, 
whose colors are applied to the vertices or faces of the 
IndexedFaceSet as follows: 
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If colorPerVertex is FALSE, colors are applied to each face, 
as follows: If the colorIndex field is not empty, then they are 
used to choose one color for each face of the 
IndexedFaceSet. There must be at least as many indices in 
the colorIndex field as there are faces in the 
IndexedFaceSet. If the greatest index in the colorIndex field 
is N, then there must be N+1 colors in the Color node. The 
colorIndex field must not contain any negative entries. If 
the colorIndex field is empty, then the colors are applied to 
each face of the IndexedFaceSet in order. There must be at 
least as many colors in the Color node as there are faces. 


W If colorPerVertex is TRUE, colors are applied to each vertex, 
as follows: If the colorIndex field is not empty, then it is 
used to choose colors for each vertex of the IndexedFaceSet 
in exactly the same manner that the coordIndex field is 
used to choose coordinates for each vertex from the Coordi- 
nate node. The colorIndex field must contain at least as 
many indices as the coordIndex field, and must contain 
end-of-face markers (—1) in exactly the same places as the 
coordIndex field. If the greatest index in the colorIndex 
field is N, then there must be N+1 colors in the Color node. 
If the colorIndex field is empty, then the coordIndex field is 
used to choose colors from the Color node. If the greatest 
index in the coordIndex field is N, then there must be N+1 
colors in the Color node. 


If the normal field is NULL, then the browser should automati- 
cally generate normals, using creaseAngle to determine if and 
how normals are smoothed across shared vertices. 

If the normal field is not NULL, then it must contain a Normal 
node, whose normals are applied to the vertices or faces of the 
IndexedFaceSet in a manner exactly equivalent to that described 
above for applying colors to vertices /faces. 

If the texCoord field is not NULL, then it must contain a 
TextureCoordinate node. The texture coordinates in that node are 
applied to the vertices of the IndexedFaceSet as follows: 

If the texCoordIndex field is not empty, then it is used to choose 
texture coordinates for each vertex of the IndexedFaceSet in 
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exactly the same manner that the coordIndex field is used to 
choose coordinates for each vertex from the Coordinate node. The 
texCoordIndex field must contain at least as many indices as the 
coordIndex field, and must contain end-of-face markers (—1) in 
exactly the same places as the coordIndex field. If the greatest 
index in the texCoordIndex field is N, then there must be N+1 
texture coordinates in the TextureCoordinate node. 

If the texCoordIndex field is empty, then the coordIndex array is 
used to choose texture coordinates from the TextureCoordinate 
node. If the greatest index in the coordIndex field is N, then there 
must be N+1 texture coordinates in the TextureCoordinate node. 

If the texCoord field is NULL, a default texture coordinate 
mapping is calculated using the bounding box of the shape. The 
longest dimension of the bounding box defines the S coordinates, 
and the next longest defines the T coordinates. If two or all three 
dimensions of the bounding box are equal, then ties should be 
broken by choosing the X, Y, or Z dimension in that order of 
preference. The value of the S coordinate ranges from 0 to 1, from 
one end of the bounding box to the other. The T coordinate ranges 
between 0 and the ratio of the second greatest dimension of the 
bounding box to the greatest dimension. 

See the introductory Geometry section for a description of the 
ccw, solid, convex, and creaseAngle fields. 


IndexedFaceSet { 


exposedField SFNode coord NULL 
field MFInt32 coordIndex [ ] 
exposedField SFNode texCoord NULL 
field MFInt32 texCoordIndex [ ] 
exposedField SFNode color NULL 
field MFInt32 colorIndex P] 
field SFBool colorPerVertex TRUE 
exposedField SFNode normal NULL 
field MFInt32 normal Index [ ] 
field SFBool normalPerVertex TRUE 
field SFBool ccw TRUE 
field SFBool solid TRUE 
field SFBool convex TRUE 


field SFFloat creaseAngle 0 
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Inline 


The Inline node is a light-weight grouping node like Group that 
reads its children from anywhere in the World Wide Web. Exactly 
when its children are read is not defined; reading the children may 
be delayed until the Inline is actually displayed. An Inline with an 
empty name does nothing. The name is an arbitrary set of URLs. 

An Inline’s URLs must refer to a valid VRML file that contains a 
grouping or leaf node. Referring to non-VRML files or VRML files 
that do not contain a grouping or leaf node is undefined. 

If multiple URLs are specified, then this expresses a descending 
order of preference. A browser may display a URL for a lower- 
preference file while it is obtaining, or if it is unable to obtain, the 
higher-preference file. See also the section on URLs and URNs. 

If the Inline’s bboxSize field specifies a non-empty bounding 
box (a bounding box is non-empty if at least one of its dimensions 
is greater than zero), then the Inline’s object-space bounding box is 
specified by its bboxSize and bboxCenter fields. This allows an 
implementation to quickly determine whether or not the contents 
of the Inline might be visible. This is an optimization hint only; if 
the true bounding box of the contents of the Inline is different 
from the specified bounding box, results will be undefined. 


Inline { 
field MFString url [ ] 
field SFVec3f bboxSize 0 
field SFVec3f bboxCenter 0 
} 


00 
00 


Prototype Definition 


PROTO Inline [ 
field MFString name a 
field SFVec3f bboxSize 000 
field SFVec3f bboxCenter 0 0 0 
ie 
DEF G Group { 
bboxSize IS bboxSize 
bboxCenter IS bboxCenter 
} 
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DEF ISCRIPT Script { 
field MFString url IS name 
eventOut MFNode children 
# 
# Script’s initialization code should call browser’s 
# createVrmlFromURL() function, then send resulting node 
# out to children eventOut. 

} 

ROUTE ISCRIPT.children TO G.addChildren 

} 
} 


IndexedLineSet 


This node represents a 3D shape formed by constructing polylines 
from vertices listed in the coord field. IndexedLineSet uses the 
indices in its coordIndex field to specify the polylines. An index of 
—1 indicates that the current polyline has ended and the next one 
begins. The last polyline may (but does not have to be) followed 
by a-l. 

For descriptions of the coord field, see the Coordinate node. 

Lines are not texture-mapped or affected by light sources. 

If the color field is not NULL, it must contain a Color node, and 
the colors are applied to the line(s) as follows: 


w If colorPerVertex is FALSE: 


If the colorIndex field is not empty, then one color is 
used for each polyline of the IndexedLineSet. There 
must be at least as many indices in the colorIndex field 
as there are polylines in the IndexedLineSet. If the 
greatest index in the colorIndex field is N, then there 
must be N+1colors in the Color node. The colorIndex 
field must not contain any negative entries. 


If the colorIndex field is empty, then the colors are 
applied to each polyline of the IndexedLineSet in order. 
There must be at least as many colors in the Color node 
as there are polylines. 
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WS If colorPerVertex is TRUE: 


If the colorIndex field is not empty, then colors are 
applied to each vertex of the IndexedLineSet in exactly 
the same manner that the coordIndex field is used to 
supply coordinates for each vertex from the Coordinate 
node. The colorIndex field must contain at least as 
many indices as the coordIndex field and must contain 
end-of-polyline markers (—1) in exactly the same places 
as the coordIndex field. If the greatest index in the 
colorIndex field is N, then there must be N+1 colors in 
the Color node. 


If the colorIndex field is empty, then the coordIndex 
field is used to choose colors from the Color node. If 
the greatest index in the coordIndex field is N, then 
there must be N+1 colors in the Color node. 


IndexedLineSet { 


exposedField SFNode coord NULL 
field MFInt32 coordIndex [] 
exposedField SFNode color NULL 
field MFInt32 colorIndex [] 
field SFBool colorPerVertex TRUE 
} 

LOD 


The LOD node (level of detail) is used to allow browsers to switch 
between various representations of objects automatically. The 
levels field contains nodes that represent the same object or objects 
at varying levels of detail, from highest detail to lowest. 

First the distance is calculated from the viewpoint, transformed 
into the local coordinate space of the LOD node (including any 
scaling transformations), to the center point of the LOD. If the 
distance is less than the first value in the range field, then the first 
level of the LOD is drawn. If between the first and second values 
in the range field, the second level is drawn, and so on. 
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If there are N values in the range field, the LOD should have 
N+1 nodes in its level field. Specifying too few levels will result in 
the last level being used repeatedly for the lowest levels of detail; 
if too many levels are specified, the extra levels will be ignored. 
The exception to this rule is to leave the range field empty, which 
is a hint to the browser that it should choose a level automatically 
to maintain a constant display rate. 

Each value in the range field should be greater than the previ- 
ous value; otherwise results are undefined. Not specifying any 
values in the range field (the default) is a special case that indi- 
cates that the browser may decide which child to draw to optimize 
rendering performance. 

Authors should set LOD ranges so that the transitions from one 
level of detail to the next are barely noticeable. Browsers may 
adjust which level of detail is displayed to maintain interactive 
frame rates, to display an already-fetched level of detail while a 
higher level of detail (contained in an Inline node) is fetched, or 
might disregard the author-specified ranges for any other imple- 
mentation-dependent reason. Authors should not use LOD nodes 
to emulate simple behaviors, because the results will be unde- 
fined. For example, using an LOD node to make a door appear to 
open when the user approaches probably will not work in all 
browsers. Use a ProximitySensor instead. 

For best results, specify ranges only where necessary, and nest 
LOD nodes with and without ranges. For example: 

LOD { 

range [100, 1000] 
levels [ 
LOD { 
levels [ 
Transform { ... detailed version... }, 
DEF LoRes Transform { ... less detailed version... } 
] 
I, 
USE LoRes, 
Shape { } # Display nothing 
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In this example, the browser is free to choose either a detailed 
or a less-detailed version of the object when the viewer is closer 
than 100 meters. The browser should display the less-detailed 
version of the object if the viewer is between 100 and 1,000 meters 
and should display nothing at all if the viewer is farther than 1,000 
meters. Browsers should try to honor the hints given by authors, 
and authors should try to give browsers as much freedom as they 
can to choose levels of detail based on performance. 


LOD { 
field MFFloat range [ ] 
field SFVec3f center 00 0 
exposedField MFNode levels [ ] 


Prototype Definition 
PROTO LOD [ 
field MFFloat range a: 
field SFVec3f center 000 
exposedField MFNode levels [ ] 
lt 


DEF F Transform { 

DEF PS ProximitySensor { center IS center } 
} 
DEF LODSCRIPT Script { 

eventOut MFNode remove 

eventOut MFNode add 

eventOut SFVec3f maxRange 

eventIn SFVec3f viewerPosition 

field MFFloat range IS range 

field MFNode levels IS levels 


= 

# Script must: 

# —-— set maxRange to maximum value in rangeL] field 

# — get viewerPosition, figure out which level should 
= be seen, add/remove appropriate children 


} 

ROUTE F.position TO LODSCRIPT.viewerPosition 
ROUTE LODSCRIPT.maxRange TO PS.size 

ROUTE LODSCRIPT.remove TO F.removeChildren 
ROUTE LODSCRIPT.add TO F.addChildren 
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Material 


The Material node defines surface material properties for associ- 
ated geometry nodes. 

The fields in the Material node determine the way light reflects 
off an object to create color: 


The diffuseColor reflects all VRML light sources depending 
on the angle of the surface with respect to the light source. 


ws The more directly the surface faces the light, the more 
diffuse light reflects. 


© The ambientIntensity field specifies how much ambient 
light from light sources this surface should reflect. Ambient 
light is omnidirectional and depends only on the number of 
light sources, not their positions with respect to the surface. 


© The specularColor and shininess determine the specular 
highlights—for example, the shiny spots on an apple. 
When the angle from the light to the surface is close to the 
angle from the surface to the viewer, the specularColor is 
added to the diffuse and ambient color calculations. Lower 
shininess values produce soft glows, while higher values 
result in sharper, smaller highlights. 


Emissive color models “glowing” objects. This can be useful for 
displaying radiosity-based models (where the light energy of the 
room is computed explicitly), or for displaying scientific data. 

Transparency is how “clear” the object is, with 1.0 being com- 
pletely transparent, and 0.0 completely opaque. 

The lighting parameters defined by the Material node are the 
same parameters defined by the OpenGL lighting model. For a 
rigorous mathematical description of how these parameters 
should be used to determine how surfaces are lit, see the descrip- 
tion of lighting operations in the OpenGL Specification. Also note 
that OpenGL specifies the specular exponent as a non-normalized 
0-128 value, which is specified as a normalized 0-1 value in VRML 
(simply multiplying the VRML value by 128 to translate to the 
OpenGL parameter). 
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For rendering systems that do not support the full OpenGL 
lighting model, the following simpler lighting model is recom- 
mended: 

A transparency value of 0 is completely opaque, a value of 1 is 
completely transparent. Browsers need not support partial trans- 
parency, but should support at least fully transparent and fully 
opaque surfaces, treating transparency values >= 0.5 as fully 
transparent. 


Issues for Low-End Rendering Systems 

Many low-end PC rendering systems are not able to support the 
full range of the VRML material specification. For example, many 
systems do not render individual red, green and blue reflected 
values as specified in the specularColor field. The following table 
describes which Material fields are typically supported in popular 
low-end systems and suggests actions for browser implementors 
to take when a field is not supported. 


Supported? Suggested Action 


ambientintensity Ignore 
diffuseColor Use 
specularColor ignore 


emissiveColor If diffuse ==OOQOthenuse 
emissive 


shininess Use 


transparency if < 0.5 then opaque else 
transparent 


The emissive color field is used when all other colors are black 
(0 0 0). Rendering systems which do not support specular color 
may nevertheless support a specular intensity. This should be 
derived by taking the dot product of the specified RGB specular 
value with the vector [.32 .57 .11]. This adjusts the color value to 
compensate for the variable sensitivity of the eye to colors. 

Likewise, if a system supports ambient intensity but not color, 
the same thing should be done with the ambient color values to 
generate the ambient intensity. If a rendering system does not 
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support per-object ambient values, it should set the ambient value 
for the entire scene at the average ambient value of all objects. 

It is also expected that simpler rendering systems may be 
unable to support both diffuse and emissive objects in the same 


world. 


Material { 
exposedField SFColor 
exposedField SFFloat 
exposedField SFColor 
exposedField SFColor 
exposedField SFFloat 
exposedField SFFloat 


MovieTexture 


diffuseColor 
ambientIntensity 
specularColor 
emissiveColor 
shininess 
transparency 


The MovieTexture node defines an animated movie texture map 
and parameters for controlling the movie and the map. MPEG1- 
Systems (audio and video) or MPEG1-Video (video-only) are 
required movie file formats. 

The duration eventOut sends the duration of the movie in 
seconds. A value of —1 implies the movie has not loaded yet; this 
eventOut value can be read to determine duration, if known. 

Movielextures are either referenced by the Appearance node’s 
texture field (as a movie texture) or by the Sound node’s source 
field (as an audio source only). 


MovieTexture { 


exposedField MFString url [ ] 
exposedField SFFloat speed 0 
exposedField SFBool loop FALSE 
exposedField SFTime startTime 0 
exposedField SFTime stopTime 0 
field SFBool repeatS TRUE 
field SFBool repeatT TRUE 
eventOut SFFloat duration 
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NavigationInfo 


The NavigationInfo node contains information for the viewer 
through several fields: type, speed, avatarSize, visibilityLimit, and 
headlight. 

The type field specifies a navigation paradigm to use. The types 
that all VRML viewers should support are “WALK”, “EXAMINE”, 
“FLY”, and “NONE”. A walk viewer is used for exploring a 
virtual world. The viewer should (but is not required to) have 
some notion of gravity in this mode. A fly viewer is similar to 
walk except that no notion of gravity should be enforced. There 
should still be some notion of “up” however. An examine viewer 
is typically used to view individual objects and often includes (but 
does not require) the ability to spin the object and move it closer 
or further away. The “none” choice removes all viewer controls. 
The user navigates using only controls provided in the scene, such 
as guided tours. Also allowed are browser specific viewer types. 
These should include a suffix as described in the naming conven- 
tions section to prevent conflicts. The type field is multi-valued so 
that authors can specify fallbacks in case a browser does not 
understand a given type. 

The speed is the rate at which the viewer travels through a 
scene in units per second. Since viewers may provide mecha- 
nisms to travel faster or slower, this should be the default or 
average speed of the viewer. In an examiner viewer, this only 
makes sense for panning and dollying—it should have no effect 
on the rotation speed. 

The avatarSize field specifies parameters to be used in deter- 
mining the camera dimensions for the purpose of collision detec- 
tion and terrain following if the viewer type allows these. It is a 
multi-value field to allow several dimensions to be specified. The 
first value should be the allowable distance between the user’s 
position and any collision geometry (as specified by Collision) 
before a collision is detected. The second should be the height 
above the terrain the camera should be maintained. The third 
should be the height of the tallest object over which the camera 
can “step.” This allows staircases to be built with dimensions that 
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can be ascended by all browsers. Additional values are browser 
dependent and all values may be ignored but if a browser inter- 
prets these values the first 3 should be interpreted as described 
above. 

The visibilityLimit field sets the furthest distance the viewer is 
able to see. The browser may clip all objects beyond this limit, 
fade them into the background or ignore this field. A value of 0.0 
(the default) indicates an infinite visibility limit. 

The headlight field specifies whether a browser should turn a 
headlight on. A headlight is a directional light that always points 
in the direction the user is looking. Setting this field to TRUE 
allows the browser to provide a headlight, possibly with user 
interface controls to turn it on and off. Scenes that enlist precom- 
puted lighting (e.g. radiosity solutions) can specify the headlight 
off here. The headlight should have intensity 1, color 111, and 
direction 0 0 -1. 

The first NavigationInfo node found during reading of the 
world supplies the initial navigation parameters. Subsequent 
NavigationInfo nodes are ignored. The browser may be told to use 
a different NavigationInfo node using Script node API calls. 


NavigationInfo { 


exposedField MFFloat avatarSize 130 
exposedField SFBool headlight TRUE 
exposedField SFFloat speed 1.0 
exposedField MFString type "WALK" 
exposedField MFFloat visibilityLimit 0.0 
eventIn SFBool bind 
eventOut SFBool isBound 
} 
Normal 


This node defines a set of 3D surface normal vectors to be used in 
the normal field of some geometry nodes (IndexedFaceSet, 
ElevationGrid). This node contains one multiple-valued field that 
contains the normal vectors. Normals should be unit-length or 
results are undefined. 
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To save network bandwidth, it is expected that implementa- 
tions will be able to automatically generate appropriate normals if 
none are given. However, the results will vary from implementa- 
tion to implementation. 

Normal { 


exposedField MFVec3f vector [] 
} 


Normallnterpolator 


This node interpolates among a set of multi-valued Vec3f values, 
suitable for transforming normal vectors. All output vectors will 
have been normalized by the interpolator. 

The number of normals in the values field must be an integer 
multiple of the number of keyframe times in the keys field; that 
integer multiple defines how many normals will be contained in 
the outValue events. 


NormalInterpolator { 


exposedField MFFloat keys [J 
exposedField MFVec3f values [J 
eventIn SFFloat set_fraction 


eventOut MFVec3f outValue 
} 


Prototype Definition 


PROTO NormalInterpolator [ 
exposedField MFFloat keys . C] 
exposedField MFVec3f values [] 
eventIn SFFloat set_fraction 
eventOut MFVec3f outValue 
]{ 
Script { 
exposedField MFFloat keys IS keys 
exposedField MFVec3f values IS values 
eventIn SFFloat set_fraction IS set_fraction 
event0Out MFVec3f outValue IS outValue 
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# 
# Does the math to map input fraction into values based 
# on keys... 
} 
} 


OrientationInterpolator 


This node interpolates among a set of SFRotation values. The 
rotations are absolute in object space and are, therefore, not cumu- 
lative. The values field must contain exactly as many rotations as 
there are keyframe times in the keys field, or an error will be 
generated and results will be undefined. 


OrientationInterpolator { 


exposedField MFFloat keys [J 
exposedField MFRotation values [] 
eventIn SFFloat set_fraction 
eventOut SFRotation outValue 

} 

Prototype Definition 

PROTO OrientationInterpolator [ 
exposedField MFFloat keys [] 
exposedField MFRotation values [] 
eventIn SFFloat set_fraction 
eventOut SFRotation outValue 

J] { 
Script { 


exposedField MFFloat keys IS keys 
exposedField MFRotation values IS values 


eventin SFFloat set_fraction IS set_fraction 
eventOut SFRotation outValue IS outValue 
# 


# Does the math to map input fraction into values based 
# on keys... 
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PixelTexture 


The PixelTexture node defines a 2D image-based texture map as 
an explicit array of pixel values and parameters controlling tiling 
repetition of the texture. 

Images may be one component (greyscale), two component 
(greyscale plus transparency), three component (full RGB color), 
or four-component (full RGB color plus transparency). An ideal 
VRML implementation will use the texture image to modify the 
diffuse color and transparency of an object’s material (specified in 
a Material node), then perform any lighting calculations using the 
rest of the object’s material properties with the modified diffuse 
color to produce the final image. The texture image modifies the 
diffuse color and transparency depending on how many compo- 
nents are in the image, as follows: 


1. Diffuse color is multiplied by the greyscale values in the 
texture image. 

2. Diffuse color is multiplied by the greyscale values in the 
texture image; material transparency is multiplied by transpar- 
ency values in texture image. 

3. RGB colors in the texture image replace the material’s diffuse 
color. 

4. RGB colors in the texture image replace the material’s diffuse 
color; transparency values in the texture image replace the 
material’s transparency. 


Browsers may approximate this ideal behavior to increase 
performance. One common optimization is to calculate lighting 
only at each vertex and combining the texture image with the 
color computed from lighting (performing the texturing after 
lighting). Another common optimization is to perform no lighting 
calculations at all when texturing is enabled, displaying only the 
colors of the texture image. 

See the SFImage field specification for details on how to specify 
an image. 
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The repeatS and repeatT fields specify how the texture wraps in 
the S and T directions. If repeatS is TRUE (the default), the texture 
map is repeated outside the 0-to-1 texture coordinate range in the 
S direction so that it fills the shape. If repeatS is FALSE, the texture 
coordinates are clamped in the S direction to lie within the 0-to-1 
range. The repeatT field is analogous to the repeats field. 


PixelTexture { 


exposedField SFImage image 000 
field SFBool repeats TRUE 
field SFBool repeatT TRUE 
} 
PlaneSensor 


The PlaneSensor maps dragging motion into a translation in two 
dimensions, in the XY plane of its local space. 
minPosition and maxPosition may be set to clamp translation 
events to a range of values as measured from the origin of the XY 
plane. If the X or Y component of minPosition is greater than the 
corresponding component of maxPosition, translation events are 
not clamped in that dimension. If the X or Y component of 
minPosition is equal to the corresponding component of 
maxPosition, that component is constrained to the given value; 
this technique provides a way to implement a line sensor that 
maps dragging motion into a translation in one dimension. 
trackPoint events provide unclamped drag position in the XY 
plane. 
PlaneSensor { 
exposedField SFVec2f minPosition 0 0 
exposedField SFVec2f maxPosition -1 -l 
exposedField SFBool enabled TRUE 
eventOut SFBool isOnPlane 
eventOut SFVec3f trackPoint 
eventOut SFVec3f translation 
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PointLight 


The PointLight node defines a point light source at a fixed 3D 
location. A point source illuminates equally in all directions; that 
is, it is omni-directional. 

See “Lights and Lighting” for an explanation of ambient light- 
ing. 

A PointLight illuminates everything within radius of its loca- 
tion. A PointLight’s illumination falls off with distance as speci- 
fied by three attenuation coefficients. The attenuation factor is 
1/(attenuation[0] + attenuation[1]*r + attenuation[2]*r“2), where r 
is the distance of the light to the surface being illuminated. The 
default is no attenuation. Renderers that do not support a full 
attenuation model may approximate as necessary. 

PointLight { 

exposedField SFBool on 

exposedField SFFloat intensity 
exposedField SFFloat ambientIntensity 
exposedField SFColor color 
exposedField SFVec3f location 
exposedField SFFloat radius 
exposedField SFVec3f attenuation 
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PointSet 


The PointSet node represents a set of points listed in the coord 
field. PointSet uses the coordinates in order. The number of points 
in the set is specified by the numPoints field. 

Points are not texture-mapped or affected by light sources. 

If the color field is not NULL, it must contain a Color node that 
contains at least numPoints colors. Colors are always applied to 
each point in order. 


PointSet { 
exposedField SFNode coord NULL 
field SFInt32 numPoints 0 


exposedField SFNode color NULL 
} 
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PositionInterpolator 


This node linearly interpolates among a set of SFVec3f values. This 
would be appropriate for interpolating a translation. 


PositionInterpolator { 


exposedField MFFloat keys [J 
exposedField MFVec3f values [J 
eventIn SFFloat set_fraction 


eventOut SFVec3f outValue 


Prototype Definition 
PROTO PositionInterpolator [ 
exposedField MFFloat keys [] 
exposedField MFVec3f values [] 
eventIn SFFloat set_fraction 


eventOut SFVec3f outValue 


]{ 
Script { 
exposedField MFFloat keys IS keys 
exposedField MFVec3f values IS values 


eventIn SFFloat set_fraction IS set_fraction 
eventOut SFVec3f outValue IS outValue 
= 
# Does the math to map input fraction into values based 
# on keys... 
} 
} 
ProximitySensor 


The ProximitySensor generates events when the viewpoint enters, 
exits, and moves inside a space. A proximity sensor can be acti- 
vated or deactivated by sending it an enabled event with a value 
of TRUE or FALSE. 
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A ProximitySensor generates isActive TRUE/FALSE events as 
the viewer enters/exits the region defined by its center and size 
fields. Ideally, implementations will interpolate viewpoint posi- 
tions and timestamp the isActive events with the exact time the 
viewpoint first intersected the volume. 

A ProximitySensor with a (0 0 0) size field (the default) will 
sense the region defined by the objects in its coordinate system. 
The axis-aligned bounding box of the Transform containing the 
ProximitySensor should be computed and used instead of the 
center and size fields in this case. 

The enterTime event is generated whenever the isActive TRUE 
event is generated, and exitTime events are generated whenever 
isActive FALSE event is generated. 

Position and orientation events giving the position and orienta- 
tion of the viewer in the ProximitySensor’s coordinate system are 
generated when either the user or the coordinate system of the 
sensor moves and the viewer is inside the region being sensed. 

Multiple ProximitySensors will generate events at the same 
time if the regions they are sensing overlap. Unlike TouchSensors, 
there is no notion of a ProximitySensor lower in the scene graph 


“grabbing” events. 


A ProximitySensor that surrounds the entire world will have an 
enter time equal to the time that the world was entered and can be 
used to start up animations or behaviors as soon as a world is 


loaded. 


ProximitySensor { 
exposedField SFVec3f 
exposedField SFVec3f 
exposedField SFBool 


eventOut SFBool 
eventOut SFVec3f 
eventOut SFRotation 
eventOut SFTime 
eventOut SFT ime 


center 0 
size 0 
enabled tT 
isActive 
position 
orientation 
enterTime 
exitTime 
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Scalarlnterpolator 


This node linearly interpolates among a set of SFFloat values. This 
interpolator is appropriate for any parameter defined using a 
single floating point value, e.g., width, radius, intensity, etc. The 
values field must contain exactly as many numbers as there are 
keyframe times in the keys field, or an error will be generated and 
results will be undefined. 


ScalarInterpolator { 


exposedField MFFloat keys [] 
exposedField MFFloat values [] 
eventIn SFFloat set_fraction 


eventOut SFFloat outValue 


Prototype Definition 


PROTO ScalarInterpolator [ 
exposedField MFFloat keys C] 
exposedField MFFloat values [] 
eventIn SFFloat set_fraction 
eventOut SFFloat outValue 
i 
Script { 
exposedField MFFloat keys IS keys 
exposedField MFFloat values IS values 


eventIin SFFloat set_fraction IS set_fraction 
eventOut SFFloat outValue IS outValue 
# 


# Does the math to map input fraction into values based 
# on keys... 
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The Script node is used to program behavior in a VRML scene. 
Script nodes typically receive events that signify a change or user 
action, contain a program module that performs some computa- 
tion, and then finally effects changes somewhere else in the world. 
Each Script node has associated code in some programming 
language that is executed to carry out the Script node’s function. 
That code will be referred to as “the script” in the rest of this 
description. 

A Script node’s scriptType field describes which scripting 
language is being used. The contents of the url field depends on 
which scripting language is being used. Typically the url field will 
contain URLs/URNs from which the script should be fetched. 

Each scripting language supported by a browser defines bind- 
ings for the following functionality. See Appendices A and B for 
the standard Java and C language bindings. 

When the script is created, any language-dependent or user- 
defined initialization is performed. The script is able to receive 
and process events that are sent to it. Each event that can be 
received must be declared in the Script node using the same 
syntax as is used in a prototype definition: 


eventIn type name 


The type can be any of the standard VRML field types, and 
name must be an identifier that is unique for this Script node. 

The Script node should be able to generate events in response to 
the incoming events. Each event that can be generated must be 
declared in the Script node using the following syntax: 


eventOut type name 


Script nodes cannot have exposedFields. The implementation 
ramifications of exposedFields is far too complex and thus not 
allowed. 

If the Script node’s mustEvaluate field is FALSE, the browser 
can delay sending input events to the script until its outputs are 
needed by the browser. If the mustEvaluate field is TRUE, the 
browser should send input events to the script as soon as possible, 
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regardless of whether the outputs are needed. The mustEvaluate 
field should be set to TRUE only if the Script has effects that are 
not known to the browser (such as sending information across the 
network); otherwise, poor performance may result. 
An example of a Script node is 
script { 

url  "http://foo.com/bar.class" 

scriptType "javabc" 

eventIn SFString name 

eventIn SFBool selected 

eventOut SFString lookto 

field SFInt32 currentState 0 

Field SFBool mustEvaluate TRUE 


The script should be able to read and write the fields of the 
corresponding Script node. The Script node cannot have exposed 
fields. 

Once the script has access to some VRML node (via an SFNode 
or MFNode value either in one of the Script node’s fields or 
passed in as an eventIn), the script should be able to read the 
contents of that node’s exposed field. If the Script node’s 
directOutputs field is TRUE, the script may also send events 
directly to any node to which it has access, and may dynamically 
establish or break routes. If directOutputs is FALSE (the default), 
then the script may only affect the rest of the world via events sent 
through its eventOuts. 

A script is able to communicate directly with the VRML 
browser to get and set global information such as navigation 
information, the current time, the current world URL, and so on. 
This is strictly defined by the API for the specific language being 
used. 

It is expected that all other functionality (such as networking 
capabilities, multi-threading capabilities, and so on) will be pro- 
vided by the scripting language. 

Script:4 

field MFString url [ ] 
field SFString scriptType 


we 
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field SFBool mustEvaluate FALSE 
field SFBool directOutputs FALSE 


# And any number of: 


eventIn eventTypeName eventName 
field fieldTypeName fieldName initialValue 
eventOut eventTypeName eventName 

Shape 


A Shape node has two fields: appearance and geometry. These 
fields, in turn, contain other nodes. The appearance field contains 
an Appearance node that has material, texture, and 
textureTransform fields (see the Appearance node). The geometry 
field contains a geometry node. The specified appearance nodes 
are applied to the specified geometry node. 
Shape { 
field SFNode appearance NULL 
field SFNode geometry NULL 


Sound 


The Sound node describes the positioning and spatial presentation 
of a sound in a VRML scene. The sound may be located at a point 
and emit sound in a spherical or ellipsoid pattern. The ellipsoid is 
pointed in a particular direction and may be shaped to provide 
more or less directional focus from the location of the sound. The 
sound node may also be used to describe an ambient sound which 
tapers off at a specified distance from the sound node. If the 
distance is set to the maximum value, the sound will be ambient 
over the entire VRML scene. 
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The source field specifies the sound source for the sound node. 
If there is no source specified the Sound will emit no audio. The 
source field must point to either an AudioClip or a MovieTexture 
node. Furthermore, the MovieTexture node must refer to a movie 
format that supports sound (e.g. MPEG1-Systems). 

The intensity field adjusts the volume of each sound source; the 
intensity is an SFFloat that ranges from 0.0 to 1.0. An intensity of 0 
is silence, and an intensity of 1 is the full volume of the sound in 
the sample or the full volume of the MIDI clip. 

The priority field gives the author some control over which 
sounds the browser will choose to play when there are more 
sounds active than sound channels available. The priority varies 
between zero and one with one being the highest priority. For 
most applications priority zero should be used for a normal sound 
and priority one should be used only for special event or cue 
sounds (usually of short duration) that the author wants the user 
to hear even if they are farther away and perhaps of lower inten- 
sity than some other ongoing sounds. Browsers should make as 
many sound channels available to the scene as is efficiently pos- 
sible. 

If the browser does not have enough sound channels to play all 
of the currently active sounds, we recommend that the browser 
sort the active sounds into an ordered list using the following sort 
keys: 

1) decreasing Priority; 2) (only for sounds with priority > 

0.5) increasing (now-startTime) 3) decreasing intensity at 

viewer location (Intensity / distance squared); 


where Priority and Intensity are fields of the sound node, now is 
the current time and startTime is the startTime field of the source 
for the sound node. 

It is important that sort key 2 be used for the high priority 
(event and cue) sounds so that new cues will be heard even when 
the channels are “full” of currently active high priority sounds. 
Sort key 2 should not be used for normal priority sounds so 
selection among them will be based on sort key 3—intensity and 
distance from the viewer. 
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The browser should play as many sounds from the beginning of 
this sorted list as it has available channels. On most systems the 
number of concurrent sound channels is distinct from the number 
of concurrent MIDI streams. On these systems the browser may 
maintain separate ordered lists for sampled sounds and MIDI 
streams. 

A sound’s location in the scene graph determines its spatial 
location (the sound’s location is transformed by the current trans- 
formation) and whether or not it can be heard. A sound can only 
be heard while it is part of the traversed scene; sound nodes 
underneath LOD nodes or Switch nodes will not be audible unless 
they are traversed. If a sound is silenced for a time under a Switch 
or LOD node, and later it becomes part of the traversal again, the 
sound picks up where it would have been had it been playing 
continuously. 

Around the location of the emitter, minFront and minBack 
determine the extent of the full intensity region in front of and 
behind the sound. If the location of the sound is taken as a focus of 
an ellipsoid, the minBack and minFront values, in combination 
with the direction vector determine the two focii of an ellipsoid 
bounding the ambient region of the sound. Similarly, maxFront 
and maxBack determine the limits of audibility in front of and 
behind the sound; they describe a second, outer ellipsoid. If 
minFront equals minBack and maxFront equals maxBack, the 
sound is omni-directional, the direction vector is ignored, and the 
min and max ellipsoids become spheres centered around the 
sound node. 

The inner ellipsoid defines an space of full intensity for the 
sound. Within that space the sound will play at the intensity 
specified in the sound node. The outer ellipsoid determines the 
maximum extent of the sound. Outside that space, the sound 
cannot be heard at all. In between the two ellipsoids, the inten- 
sity drops off proportionally with inverse square of the distance. 
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With this model, a sound usually will have smooth changes in 
intensity over the entire extent is which it can be heard. How- 
ever, if at any point the maximum is the same as or inside the 

minimum, the sound is cut off immediately at the edge of the 

minimum ellipsoid. 

Browsers should support spatial localization of sound as well as 
their underlying sound libraries will allow. The spatialize field is 
used to indicate to browsers that they should try to locate this 
sound. If the spatialize field is TRUE, the sound should be treated 
as a monaural sound coming from a single point. A simple 
spatialization mechanism just places the sound properly in the 
pan of the stereo (or multichannel) sound output. Sounds are 
faded out over distance as described above. Browsers may use 
more elaborate sound spatialization algorithms if they wish. 

Authors can create ambient sounds by setting the spatialize 
field to FALSE. In that case, stereo and multichannel sounds 
should be played using their normal separate channels. The 
distance to the sound and the minimum and maximum ellipsoids 
(discussed above) should affect the intensity in the normal way. 
Authors can create ambient sound over the entire scene by setting 
the minFront and minBack to the maximum value. 

Sound { 

exposedField SFNode = source 
exposedField SFFloat intensity 
exposedField SFFloat priority 


NULL 
1 
0 
exposedField SFVec3f location 0 
0 
1 
1 
1 


0 0 
exposedField SFVec3f direction 01 
exposedField SFFloat minFront 
exposedField SFFloat maxFront 
exposedField SFFloat minBack 


exposedField SFFloat maxBack 10 
field SFBool spatialize TRUE 


0 


The Sphere node represents a sphere. By default, the sphere is 
centered at the origin and has a radius of 1. 

Spheres generate their own normals. When a texture is applied 
to a sphere, the texture covers the entire surface, wrapping coun- 
terclockwise from the back of the sphere. The texture has a seam at 
the back on the YZ plane. 


Sphere { 
field SFFloat radius 1 
} 


Prototype Definition 


PROTO Sphere [ 
field SFFloat radius 1 
Lt 
. equivalent to an IndexedFaceSet plus generator 
Ser leas 


SphereSensor 


The SphereSensor maps dragging motion into a free rotation 
about its center. The feel of the rotation is as if you were rolling a 
ball. 


SphereSensor { 
exposedField SFBool enabled TRUE 


event0Out SFBool isActive 
event0Out SFVec3f trackPoint 
event0Out SFRotation rotation 


eventOut SFBool onSphere 


The free rotation of the SphereSensor is always unclamped. 
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Upon the initial click down on the SphereSensor’s geometry, the 
point hit determines the radius of the sphere used to map pointing 
device motion while dragging. trackPoint events always reflect the 
unclamped drag position on the surface of this sphere, or in the 
plane perpendicular to the view vector if the cursor moves off of 
the sphere. An onSphere TRUE event is generated at the initial 
click down; thereafter, onSphere FALSE/TRUE events are gener- 
ated if the pointing device is dragged off/on the sphere. 


SpotLight 


The SpotLight node defines a light source that is placed at a fixed 
location in 3-space and illuminates in a cone along a particular 
direction. 

See “Lights and Lighting” for an explanation of ambient light- 
ing. 

The cone of light extends a maximum distance of radius from 
its location. The light’s illumination falls off with distance as 
specified by three attenuation coefficients. The attenuation factor 
is 1/(attenuation[0] + attenuation[1]*r + attenuation[2]*r‘%2), 
where r is the distance of the light to the surface being illumi- 
nated. The default is no attenuation. Renderers that do not sup- 
port a full attenuation model may approximate as necessary. 

The intensity of the illumination may drop off as the ray of light 
diverges from the light’s direction toward the edges of the cone. 
The angular distribution of light is controlled by the cutOffAngle, 
beyond which the illumination is zero, and the beamWidth, the 
angle at which the beam starts to fall off. Renderers that support a 
two cone model with linear fall off from full intensity at the inner 
cone to zero at the cutoff cone should use beamWidth for the inner 
cone angle. Renderers that attenuate using a cosine raised to a 
power should use an exponent of exponent = 0.5*log(0.5) / 
log(cos(beamWidth)). When beamWidth >= PI/2 the illumination 
is uniform up to the cutoff angle, which is the default. 


SpotLight { 
exposedField SFBool on TRUE 
exposedField SFFloat intensity i 


exposedField SFFloat ambientIntensity 0 
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exposedField SFColor color | a aoe | 
exposedField SFVec3f location 000 
exposedField SFVec3f direction OO: 
exposedField SFFloat beamWidth 1.570796 
exposedField SFFloat cut0ffAngle 0.785398 
exposedField SFFloat radius 1 
exposedField SFVec3f attenuation 100 
} 
Switch 


The Switch grouping node traverses zero or one of its children 
(which are specified in the choices field). 

The whichChild field specifies the index of the child to traverse, 
where the first child has index 0. If whichChild is less than zero or 
greater than the number of nodes in the choices field then nothing 
is chosen. 


Switch { 
exposedField SFInt32 whichChild -1 
exposedField MFNode choices [ ] 
} 


Prototype Definition 


PROTO Switch [ 
exposedField SFInt32 whichChild -1 
exposedField MFNode choices [ ] 
1 { 
DEF F Transform { 
} 
DEF SWITCHSCRIPT Script { 
eventOut MFNode remove 
eventOut MFNode add 
exposedField SFInt32 whichChild IS whichChild 
exposedField MFNode choices IS choices 
# 
# Script must: 
# — keep whichChild up-to-date 
#  - figure out which child should 
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s be seen when whichChild changes, add/remove 
# appropriate children 

} 

ROUTE SWITCHSCRIPT.remove TO F.removeChildren 

ROUTE SWITCHSCRIPT.add TO F.addChildren 


} 


Text 


The Text node represents one or more text strings specified using 
the UTF-8 encoding as specified as by the ISO 10646-1:1993 stan- 
dard. Due to the drastic changes in Korean Jamo language, the 
character set of the UTF-8 will be based on ISO 10646-1:1993 plus 
pDAM 1 - 5 (including the Korean changes). The text strings are 
stored in visual order. 

The text strings are contained in the string field. The fontStyle 
field contains one FontStyle node that specifies the font size, font 
family and style, direction of the text strings, and any specific 
language rendering techniques that must be used for the text. 

The maxExtent field limits and scales the text string if the 
natural length of the string is longer than the maximum extent, as 
measured in the local coordinate space. If the text string is shorter 
than the maximum extent, it is not changed. The maximum extent 
is measured horizontally for horizontal text (FontStyle node: 
horizontal=TRUE) and vertically for vertical text (FontStyle node: 
horizontal=FALSE). 

The length field contains an MFFloat value that specifies the 
length of each text string in the local coordinate space. If the string 
is too short, it is stretched (either by scaling the text or by adding 
space between the characters). If the string is too long, it is com- 
pressed (either by scaling the text or by subtracting space between 
the characters). If a length value is missing—for example, if there 
are four strings but only three length values—the missing values 
are considered to be 0. 

For both the maxExtent and length fields, specifying a value of 
0 indicates to allow the string to be any length. 
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Textures are applied to 3D text as follows: The texture origin is 
at the origin of the first string, as determined by the justification. 
The texture is scaled equally in both S and T dimensions, with the 
font height representing 1 unit. S increases to the right, and T 
increases up. 


ISO 10646-1:1993 Character Encodings 


Characters in ISO 10646 are encoded in multiple octets. Code 
space is divided into four units, as follows: 
4$-------------+-------------4---- == === == === == + 


| Group-octet | Plane-octet | Row-octet | Cell-octet | 


+-------------4$--- === === === == + === === === + 


The ISO 10646-1:1993 allows two basic forms for characters: 

1. UCS-2 (Universal Coded Character Set-2). Also known as the 
Basic Multilingual Plane (BMP). Characters are encoded in the 
lower two octets (row and cell). Predictions are that this will 
be the most commonly used form of 10646. 

2. UCS-4 (Universal Coded Character Set-4). Characters are 
encoded in the full four octets. 

In addition, three transformation formats (UCS Transformation 
Format (UTF) are accepted: UTF-7, UTF-8, and UTF-16. Each 
represents the nature of the transformation—7-bit, 8-bit, and 
16-bit. The UTF-7 and UTF-16 can be referenced in the Unicode 
Standard 2.0 book. 

The UTF-8 maintains transparency for all of the ASCII code 
values (0...127). It allows ASCII text (0x0..0x7F) to appear without 
any changes and encodes all characters from 0x80.. 0x7FFFFFFF 
into a series of six or fewer bytes. 

If the most significant bit of the first character is 0, then the 
remaining seven bits are interpreted as an ASCII character. Other- 
wise, the number of leading 1 bits will indicate the number of 
bytes following. There is always a 0 bit between the count bits and 
any data. 
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First byte could be one of the following. The X indicates bits 
available to encode the character. 


OXXXXXXX only one byte —_0..0x7F (ASCII) — 

LLOXXXXX two bytes = Maximum character value is Ox7F _ 
111 0XXXX three bytes Maximum character value is OxFFFF 
11110XXxX four bytes Maximum character value is Ox FFFFF 


111110XxX five bytes = Maximum character value ‘is OxSFFFFFF 
1111110X six bytes = = = Maximum character value is x7 FFFFFFF | 
All following bytes have LOXXXXXX  —r—™ 
this format 


A two byte example: The symbol for a registered trademark is 
“circled R registered sign” or 174 in ISO/Latin-1 (8859/1). It is 
encoded as Ox00AE in UCS-2 of the ISO 10646. In UTF-8 it has the 
following two byte encoding: 0xC2, OxAE. 


Text { 
exposedField MFString string a 
field SFNode fontStyle NULL 
field SFFloat maxExtent 0.0 
field MFFloat length [ ] 
} 

Texture Transform 


The TextureTransform node defines a 2D transformation that is 
applied to texture coordinates. This node is used only in the 
textureTransform field of the Appearance node and affects the 
way textures are applied to the surfaces of the associated Geom- 
etry node. The transformation consists of (in order) a nonuniform 
scale about an arbitrary center point, a rotation about that same 
point, and a translation. This allows a user to change the size and 
position of the textures on shapes. 


oy 
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TextureTransform { 
exposedField SFVec2f translation 0 0 
exposedField SFFloat rotation 0 
exposedField SFVec2f scale 1 
exposedField SFVec2f center 0 


1 
0 


TextureCoordinate 


This node defines a set of 2D coordinates to be used in the 
texCoord field to map textures to the vertices of some geometry 
nodes (IndexedFaceSet and ElevationGrid). 

Texture coordinates range from 0 to 1 across the texture image. 
The horizontal coordinate, S, is specified first, followed by the 
vertical coordinate, T. 

TextureCoordinate { 

exposedField MFVec2f point [] 
} 


TimeSensor 


TimeSensors generate events as time passes. TimeSensors remain 
inactive until their startTime is reached. At the first simulation tick 
when “now” is greater than or equal to startTime, the TimeSensor 
will begin generating time and fraction events, which may be 
routed to other nodes to drive continuous animation or simulated 
behaviors. 

The length of time a TimeSensor generates events is controlled 
using cycleInterval and loop; a TimeSensor stops generating time 
events at time startTime+cycleInterval if loop is FALSE. If loop is 
TRUE, the TimeSensor loops forever. The time events contain 
absolute times so they will start at startTime and increase up to 
startTime+cycleInterval if loop is FALSE, and forever if loop is 
TRUE. 

TimeSensors ignore changes to their startTime while they are 
actively outputting values. If a set_startTime event is received 
while the TimeSensor is active, then that set_startTime event is 
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ignored (the startTime field is not changed, and a 
startTime_changed eventOut is NOT generated). A TimeSensor 
may be re-started while it is active by sending it a set_stopTime 
“now” event (which will cause the TimeSensor to become inac- 
tive) and then sending it a set_startTime event (setting it to “now” 
or any other starting time, in the future or past). 

If the enabled exposedField is TRUE, the TimeSensor behaves 
as described. When enabled is FALSE the TimeSensor does not 
generate outputs and isActive is set to FALSE, and vice versa. 

The discrete field controls the output of time and fraction 
events. If discrete is FALSE (the default), then fraction events will 
rise from 0.0 to 1.0 over each cycleInterval, and time events will be 
generated continuously over each cycleInterval. If discrete is 
TRUE, then fraction events are not generated and time events are 
generated at startTime and at the end of each cycleInterval. 

stopTime may be set to interrupt the progress of a TimeSensor. 
If stopTime is greater than startTime, time and fraction events will 
not be generated after the pause time. stopTime is ignored if it is 
less than or equal to startTime. 

A TimeSensor will generate an isActive TRUE event when it 
begins generating times, and will generate an isActive FALSE 
event when it stops generating times (either because stopTime 
was reached or because time loop is FALSE and 
startTime+cycleInterval was reached). 

Setting the loop field to TRUE makes the TimeSensor start 
generating events at startTime and continue generating events 
forever (or until stopTime is reached). This use of the TimeSensor 
should be used with caution, since it incurs continuous overhead 
on the simulation. By combining the loop and stopTime fields a 
TimeSensor that repeats something N times can be created as 
follows: 

TimeSensor { 

startTime qT 
cycleInterv I 


loop TRUE 
stopTime T+1#N 
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Setting loop to FALSE and cycleInterval to 0 will result in a 
single event being generated at startTime; this can be used to build 
an alarm that goes off at some point in the future. 

No guarantees are made with respect to how often a 
TimeSensor will generate time events, but TimeSensors are guar- 
anteed to generate final fraction and time events at or after time 
(startTime+cycleInterval) if loop is FALSE and stopTime is less 
than or equal to startTime. 


TimeSensor { 
exposedField SFTime cyclelInterval 0 


exposedField SFBool discrete FALSE 
exposedField SFBool enabled TRUE 
exposedField SFBool loop FALSE 
exposedField SFTime  stopTime 0 
exposedField SFTime  startTime 0 
eventOut SFBool isActive 
eventOut SFFloat fraction 
eventOut SFTime time 
} 
Examples: 


1. Animate a cube when the user clicks on it: 


DEF XForm Transform { children [ 
Shape { geometry Box { } }, 
DEF Clicker TouchSensor { }, 
DEF TimeSource TimeSensor { 
cycleInterval 2.0 # Will run once for 2 seconds 
Js 
# Animate one full turn about Y axis 
# (need 4 keyframes to make it well—determined): 
DEF Animation OrientationInterpolator { 
keys [ 0, [38% .66, 1 
values [0100, 0102.1, 010 4.2, 0 
} 
}} 
ROUTE Clicker.clickTime TO TimeSource.startTime 
ROUTE TimeSource. fraction TO Animation.set_fraction 
ROUTE Animation.outValue TO XForm.rotation 
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2. Play Westminster Chimes once an hour: 


Group { children [ 
DEF Hour TimeSensor { 


discrete TRUE 
loop TRUE 
cycleInterval 3600.0 # 60*60 seconds == 1 hour 


}, 
DEF Sounder Sound { 
name "http://..... /westminster.mid" 
} 
]} 
ROUTE Hour.time TO Sounder.startTime 


3. Make a grunting noise when the user runs into a wall: 


DEF Walls Collision { children [ 
Transform { 
#... geometry of walls... 
V3 
DEF Grunt Sound { 
name "http://..... /grunt.wav" 
} 
]} 
ROUTE Walls.collision TO Grunt.startTime 


TouchSensor 


A TouchSensor tracks the pointing device with respect to its 
sibling nodes. This sensor can be activated or deactivated by 
sending it an enabled event with a value of TRUE or FALSE. 

The TouchSensor generates events as the pointing device 
“passes over” the geometry defined by nodes that are children of 
the TouchSensor’s parent Group or Transform. Typically, the 
pointing device is a 2D device such as a mouse. In this case, the 
pointing device is considered to be moving within a plane a fixed 
distance from the camera and perpendicular to the line of sight; 
this establishes a set of 3D coordinates for the pointer. If a 3D 
pointer is in use, then the TouchSensor only generates events 
when the pointer is within the user’s field of view. In either case, 
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the pointing device is considered to “pass over” geometry when 
the geometry is intersected by a line extending from the camera 
and passing through the pointer’s 3D coordinates. If multiple 
surfaces intersect this line (hereafter called the bearing), only the 
nearest will be eligible to generate events. 

TRUE/FALSE events are generated as the pointing device 
“passes over” the TouchSensor’s geometry. When the pointing 
device moves to a position such that its bearing intersects the 
TouchSensor’s geometry, an isOver TRUE event should be gener- 
ated. When the pointing device moves to a position such that its 
bearing no longer intersects the geometry, or some other geometry 
is obstructing the TouchSensor’s geometry, an isOver FALSE event 
should be generated. All of these events are generated only when 
the pointing device has moved; events are not generated if the 
geometry itself is animating and moving underneath the pointing 
device. 

The user may manipulate the pointing device to cause the 
TouchSensor to generate isActive events. When the TouchSensor 
generates an isActive TRUE event, it will grab all further motion 
events from the pointing device until it releases and generates an 
isActive FALSE event (other Touch and Drag sensors will not 
generate events during this time). Motion of the pointing device 
while isActive is TRUE is referred to as a “drag”. If a 2D pointing 
device is in use, isActive events will typically reflect the state of 
the primary button associated with the device (i.e. isActive is 
TRUE when the primary button is pressed, and FALSE when not 
released). If a 3D pointing device is in use, isActive events will 
typically reflect whether the pointer is within or in contact with 
the TouchSensor’s geometry. 

As the user drags the bearing over the TouchSensor’s geometry 
(with isActive TRUE), the point of intersection (if any) is deter- 
mined. When isOver is TRUE, each drag of the pointing device 
generates hitPoint, hitNormal, and hitTexCoord events. hitPoint 
events contain the 3D point on the surface of the underlying 
geometry, given in the TouchSensor’s coordinate system. 
hitNormal events contain the surface normal at the hitPoint. 
hitTexCoord events contain the texture coordinates of that surface 
at the hitPoint, which can be used to support the 3D equivalent of 
an image map. 
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The eventOut field touchTime is generated when all three of the 
following are true: 


© the pointing device was over the geometry when it was 
initially touched, 


the pointing device is currently over the geometry (isOver 
was/is TRUE), 


and, the pointing device’s button is released (isActive 
FALSE event is also generated). 


TouchSensor { 

exposedField SFBool enabled TRUE 
eventOut SFBool isOver 
eventOut SFBool isActive 
eventOut SFVec3f hitPoint 
eventOut SFVec3f hitNormal 
eventOut SFVec2f hitTexCoord 
eventOut SFTime touchTime 


Transform 


A Transform is a grouping node that defines a coordinate system 
for its children that is relative to the coordinate systems of its 
parents. See also “Coordinate Systems and Transformations.” 

The bboxCenter and bboxSize fields may be used to specify a 
maximum possible bounding box for the objects inside this Trans- 
form. These are hints to the browser that it may use to optimize 
certain operations such as determining whether or not the Trans- 
form needs to be drawn. If the specified bounding box is smaller 
than the true bounding box of the Transform, results are unde- 
fined. The bounding box should be large enough to completely 
contain the effects of all sounds, lights and fog nodes that are 
children of this Transform. If the size of this Transform may 
change over time because its children are animating (moving), 
then the bounding box must also be large enough to contain all 
possible animations (movements). The bounding box should be 
only the union of the Transform’s children’s bounding boxes; it 
should not include the Transform’s transformation. 
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The add_children event adds the nodes passed in to the 
Transform’s children field. Any nodes passed in the add_children 
event that are already in the Transform’s children list are ignored. 
The remove_children event removes the nodes passed in from the 
Transform’s children field. Any nodes passed in the 
remove_children event that are not in the Transform’s children list 
are ignored. 

The translation, rotation, scale, scaleOrientation and center 
fields define a geometric 3D transformation consisting of (in 
order) a (possibly) non-uniform scale about an arbitrary point, a 
rotation about an arbitrary point and axis, and a translation. 


The Transform Node 


Transform { 
translation Tl 
rotation Rl 
scale S 
scaleOrientation R2 
center 12 


is equivalent to the nested sequence of: 


Transform { translation Tl 
Transform { translation T2 
Transform { rotation Rl 
Transform { rotation R2 
Transform { scale §S 
Transform { rotation -R2 
Transform { translation -T2 


WEdEETS 


Transform { 


field SFVec3f bboxCenter 000 
field SFVec3f bboxSize 000 
exposedField SFVec3f translation 000 
exposedField SFRotation rotation 001 0 
exposedField SFVec3f scale oe 
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exposedField SFRotation scaleOrientation001 0 
exposedField SFVec3f center 000 
exposedField MFNode children [ ] 
eventIn MFNode add_children 
eventIn MFNode remove_children 
} 
Viewpoint 


The Viewpoint node defines a specific location in a local coordi- 
nate system from which the user might wish to view the scene. 
Viewpoints are bindable leaf nodes and there exists a Viewpoint 
stack in the browser, in which the topmost Viewpoint on the stack 
is the currently active viewpoint. To push a Viewpoint onto the 
top of the stack, a TRUE value is sent to the bind eventIn on the 
specific Viewpoint. Once active, the viewpoint is then bound to 
the browser’s view. All subsequent changes (e.g. animations) to 
the viewpoint automatically change the user’s view. A FALSE 
value of bind pops the viewpoint from the stack and unbinds it 
from the browser viewer. See “Bindable Leaf Nodes” for more 
details on the Viewpoint stack. | 

An author can automatically move the user’s view through the 
world by binding the user to a viewpoint and then animating that 
viewpoint. 

The position and orientation fields of the Viewpoint node 
specify relative locations in the local coordinate system. Position is 
relative to the coordinate system’s origin (0,0,0), while orientation 
specifies a rotation relative to the default orientation; the default 
orientation has the user looking down the —Z axis with +X to the 
right and +Y straight up. Note that the single orientation rotation 
(which is a rotation about an arbitrary axis) is sufficient to com- 
pletely specify any combination of view direction and “up” vector. 

The fieldOfView field specifies a preferred field of view from 
this viewpoint, in radians. A smaller field of view corresponds to a 
telephoto lens on a camera; a larger field of view corresponds to a 
wide-angle lens on a camera. The field of view should be greater 
than zero and smaller than PI; the default value corresponds to a 
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45 degree field of view. fieldOfView is a hint to the browser and 
may be ignored. A browser rendering the scene into a rectangular 
window will ideally scale things such that a solid angle of 
fieldOfView from the viewpoint in the view direction will be 
completely visible in the window. 

A viewpoint can be placed in a VRML world to specify the initial 
location of the viewer when that world is entered. Browsers should 
recognize the URL syntax ”..../scene.wrl#ViewpointName” as 
specifying that the user’s initial view when entering the 
“scene.wrl” world should be the first viewpoint in file “scene.wrl” 
that appears as “DEF ViewpointName Viewpoint { ... }”. 

The description field can be used to identify viewpoints to be 
made publicly accessible through a viewpoints menu or some 
other device. The string in the description field should be shown 
in the interface if this functionality is implemented. If no descrip- 
tion is given, then this Viewpoint should never appear in any 
public interface. It is suggested that the browser move to a view- 
point when its description is selected, either animating to the new 
position or jumping directly there. Once the new position is 
reached both the isBound and bindTime eventOuts should be sent. 

A TRUE value sent to the bind eventIn pushes a given View- 
point to the top of the Viewpoint stack in the browser. The 
bindTime eventOut sends the time at which the Viewpoint is 
bound. This is useful for starting an animation or script when a 
given Viewpoint becomes active. 

If a browser has the capability to go to a named viewpoint, it 
should bind to that viewpoint and issue an isBound TRUE 
eventOut on that viewpoint. 


Viewpoint { 
exposedField SFVec3f position 000 
exposedField SFRotation orientation 001 0 
exposedField SFFloat field0fView 0.785398 
field SFString description _ 
eventIn SFBool bind 


eventOut SFT ime bindTime 
eventOut SFBool isBound 
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VisibilitySensor 


The VisibilitySensor detects visibility changes of a bounding box 
as the user navigates the world. It outputs a TRUE event when 
any portion of the box enters the viewing frustum, and a FALSE 
event when the box completely exits the frustum. The 
VisibilitySensor does not detect occlusion by other objects—it 
compares the bounding box to the viewing frustum regardless of 
other geometry in the world. Browsers must be conservative by 
guaranteeing that if isVisible is FALSE that the bounding box is 
definitely completely outside the viewing frustum—browsers can 
error liberally when on isVisible is TRUE (e.g., maybe it is visible). 
The bounding box specified by VisibilitySensor is affected by 
the current transform. 
VisibilitySensor is typically used to detect when the user can see 
a specific object or area, and to activate or deactivate some behav- 
ior or animation in order to attract the user or improve perfor- 
mance. 
VisibilitySensor { 
exposedField SFVec3f bboxCenter 0 0 0 
exposedField SFVec3f bboxSize 000 


exposedField SFBool isActive TRUE 
eventOut SFBool isVisible 


WorldInfo 


The WorldInfo node contains information about the world. The 
title of the world is stored in its own field, allowing browsers to 
display it—for instance, in their window border. Any other infor- 
mation about the world can be stored in the info field—for in- 
stance, the scene author, copyright information, and public do- 
main information. 
WorldInfo { 
field SFString title "" 
field MFString info [ ] 
} 
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chapter six 


Field Types 


There are two general classes of fields; fields that contain a single 
value (where a value may be a single number, a vector, or even an 
image), and fields that contain multiple values. Single-valued 
fields all have names that begin with SF; multiple-valued fields 
have names that begin with MF. Each field type defines the format 
for the values it writes. 

Multiple-valued fields are written as a series of values sepa- 
rated by commas, all enclosed in square brackets. If the field has 
zero values, then only the square brackets (“[]’”) are written. The 
last may optionally be followed by a comma. If the field has 
exactly one value, the brackets may be omitted and just the value 
written. For example, all of the following are valid for a multiple- 
valued field containing the single integer value 1: 

1 


oe 
ee 
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SFBool 


A field containing a single boolean (true or false) value. SFBools 
are written as TRUE or FALSE. 


SFColor/MFColor 


Fields containing one (SFColor) or zero or more (MFColor) RGB 
colors. Each color is written to file as an RGB triple of floating 
point numbers in ANSI C floating point format, in the range 0.0 to 
1.0. For example: 


[10 0. 0.0; 01:0, 2051-3] 


is an MFColor field containing the three colors red, green, and 
blue. 


SFFloat/MFFloat 


Fields that contain one (SFFloat) or zero or more (MFFloat) single- 
precision floating point number. SFFloats are written to file in 
ANSI C floating point format. For example: 


[ 3.1415926, 12.5e-3, .0001 ] 


is an MFFloat field containing three values. 


SFlmage 


A field that contains an uncompressed 2-dimensional color or 
greyscale image. SFImages are written to file as three integers 
representing the width, height and number of components in the 
image, followed by width*height hexadecimal values representing 
the pixels in the image, separated by whitespace. A one-compo- 
nent image will have one-byte hexadecimal values representing 
the intensity of the image. For example, OxFF is full intensity; 0x00 
is no intensity. A two-component image puts the intensity in the 
first (high) byte and the transparency in the second (low) byte. 
Pixels in a three-component image have the red component in the 
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first (high) byte, followed by the green and blue components (so 
OxFFO000 is red). Four-component images put the transparency 
byte after red/green/blue (so OxO000FF80 is semi-transparent 
blue). A value of OxFF is completely transparent; 0x00 is com- 
pletely opaque. 

Note: Each pixel is actually read as a single unsigned number, 
so a 3-component pixel with value “Ox0000FF” can also be written 
as “OxFF” or “255” (decimal). Pixels are specified from left to right, 
bottom to top. The first hexadecimal value is the lower left pixel of 
the image, and the last value is the upper right pixel. 

For example, 


1 2 1 OXxFF 0x00 
is a 1-pixel-wide by 2-pixel-high greyscale image, with the bottom 
pixel white and the top pixel black. And: 

2 4 3 OxFFOO00 OxFFOO 0 0 O O OXFFFFFF OxFFFFOO 
is a 2-pixel-wide by 4-pixel-high RGB image, with the bottom left 
pixel red, the bottom right pixel green, the two middle rows of 
pixels black, the top left pixel white, and the top right pixel yellow. 


SFint32/MFint32 


Fields containing one (SFInt32) or zero or more (MFInt32) 32-bit 
integers. SFInt32s are written to file as an integer in decimal or 
hexadecimal (beginning with ‘Ox’) format. For example: 


L 17, =OxE20, -518820 J 


is an MFInt32 field containing three values. 


SFNode/MFNode (new) 


A field containing one or several nodes. A node field’s syntax is 
just the node that it contains; for example, this is valid syntax for 
an MFNode field: 


[ Transform { translation 1 0 0 }, DEF CUBE Cube { }, USE 
SOME_NODE ] 


An SFNode field may also contain the keyword NULL to 
indicate that it contains nothing. 
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SFRotation/MFRotation 


A field containing an arbitrary rotation. SFRotations are written to 
file as four floating point values separated by whitespace. The 4 
values represent an axis of rotation followed by the amount of 
right-handed rotation about that axis, in radians. For example, a 
180 degree rotation about the Y axis is: 


010 3.14159265 


SFString/MFString 


Fields containing one (SFString) or zero or more (MFString) UTF-8 
string (sequence of characters). Strings are written to file as a 
sequence of UTF-8 octets in double quotes. Any characters (in- 
cluding newlines and ‘#’) may appear within the quotes. To 
include a double quote character within the string, precede it with 
a backslash. To include a backslash character within the string, 
type two backslashes. For example: 


"One, Two, Three" 
"He said, \"Immel did it!\"" 


are both valid strings. 


SFTime/MF Time (new) 


Field containing a single time value. Each time value is written to 
file as a double-precision floating point number in ANSI C float- 
ing point format. An absolute SFTime is the number of seconds 
since Jan 1, 1970 GMT. 


SFVec2fi/MFVec2f 


Field containing a two-dimensional vector. SFVec2fs are written to 
file as a pair of floating point values separated by whitespace. 
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SFVec3f/MFVec3f 


Field containing a three-dimensional vector. SFVec3fs are written 
to file as three floating point values separated by whitespace. 


Syntax Summary (BNF) 


This section describes the syntax (grammar) of the Moving Worlds 
human-readable file format. 

This grammar is ambiguous; semantic knowledge of the names 
and types of fields, eventIns, and eventOuts for each node type 
(either builtIn or userDefined using PROTO or EXTERNROTO) 
must be used during parsing so that the parser knows which field 
type is being parsed. 

Please see the Nodes Reference section of the Moving Worlds 
specification (Chapter 5 of this book) for a description of the 
allowed fields, eventIns and eventOuts for all pre-defined node 
types. Also note that some of the basic types that will typically be 
handled by a lexical analyzer (sffloatValue, sftimeValue, 
sfint32Value, and sfstring Value) have not been formally specified; 
please see the Fields Reference section of the spec for a more 
complete description of their syntax. 


General 


vrml Scene: 
declarations 
declarations: 
declaration 
declaration declarations 
declaration: 
nodeDeclaration 
protoDeclaration 
routeDeclaration 
nodeDeclaration: 
node 
DEF nodeNameld node 
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USE nodeNameld 
protoDeclaration: 

proto 

externproto 
proto: 

PROTO nodeTypeld [ interface_declarations ] { vrmlScene 
} 
interfaceDeclarations: 

interfaceDecl aration 

interfaceDeclaration interfaceDeclarations 
interfaceDeclaration: 

eventIn fieldlype eventInId 

eventOut fieldlype eventOutId 

field fieldType fieldId fieldValue 

exposedField fieldType fieldId fieldValue 
externproto: 

EXTERNPROTO nodeTypeld [ externInterfaceDeclarations ] 
mfstringValue 
externInterfaceDeclarations: 

externInterfaceDecl aration 

externInterfaceDeclaration externInterfaceDeclarations 
externInterfaceDecl aration: 

eventIn fieldType eventInId 

eventOut fieldType eventOutId 

field fieldType fieldId 

exposedField fieldType fieldId 
routeDeclaration: 

ROUTE nodeNameId . eventOutId TO nodeNameld . eventInId 


Nodes 


node: 

nodeTypeld { nodeGuts } 

Script { scriptGuts } 
nodeGuts: 

nodeGut 

nodeGut nodeGuts 
scriptGuts: 

scriptGut 

scriptGut scriptGuts 
scriptGut: 
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nodeGut 

interfaceDeclaration 
nodeGut: 

fieldId fieldValue 

fieldiId IS fieldId 

eventInId IS eventInId 

eventOutId IS eventOutId 


routeDeclaration 
protoDeclaration 
nodeNameld: 
Id 
nodeTypeld: 
Id 
fieldld: 
Id 
eventinId: 
Id 
eventOutId: 
Id 
Id: 
IdFirstChar 
IdFirstChar IdRestChars 
IdFirstChar: 


Any ISO-10646 character encoded using UTF-8 except: 
0x30-0x39, 0x0-0x20, 0x22, 0x23, 0x27, Ox2c, O0x2e, 

Ox5b, Oxdc, Ox5d, Ox7b, Ox/7d. 
IdRestChars: 

Any number of ISO-10646 characters except: 0x0-0x20 
0x22, 0x23, 0x27, Ox2c, Ox2e, Ox5b, Ox5c, Ox5d, Ox7b, 

Ox7d. 


’ 


Fields 


fieldType: 

MFColor 
MFFloat 

MF Int32 

MF Node 
MFRotation 
MFString 
MF Vec2f 
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MF Vec3f 
SFBool 
SFColor 
SFFloat 
SF Image 
SF Int32 
SFNode 
SFRotation 
SFString 
SFT ime 
SFVec2f 
SFVec3f 
fieldValue: 
sfboolValue 
sfcolorValue 
sffloatValue 
sfimageValue 
sfint32Value 
sfnodeValue 
sfrotationValue 
sfstringValue 
sftimeValue 
sfvec2fValue 
sfvec3fValue 
mfcolorValue 
mffloatValue 
mfint32Value 
mfnodeValue 
mfrotationValue 
mfstringValue 
mfvec2fValue 
mfvec3fValue 
sfboolValue: 
TRUE: 
FALSE 
sfcolorValue: 
float float float 
sffloatValue: 

. floating point number in ANSI C floating point 
format... 
sfimageValue: 

int32 int32 int32 int32s... 
sfint32Value: 
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[0-9]+ 

Ox[0-9A-F ]+ 
sfnodeValue: 

nodeDecl aration 

NULL 
SfrotationValue: 

float float float float 
sfstringValue: 

".*" .~., double-quotes must be \", backslashes must be 
Nas 
sftimeValue: 

. double-precision number in ANSI C floating point 

format... 
sfvec2fValue: 

float float 
sfvec3fValue: 

float float float 
mfcolorValue: 

sfcolorValue 

C ] 

[ sfcolorValues ] 

[ sfcolorValues , ] 
sfcolorValues: 

sfcolorValue 

sfcolorValue , sfcolorValues 
mffloatValue: 

sffloatValue 

[ ] 

[ sffloatValues ] 

[ sffloatValues , ] 
sffloatValues: 

sffloatValue 

sffloatValue , sffloatValues 
mfint32Value: 

sfint32Value 

[ ] 

[ sfint32Values ] 

[ sfint32Values , ] 
sfint32Values: 

sfint32Value 

sfint32Value , sfint32Values 
mfnodeValue: 

nodeDeclaration 
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[ ] 

[ nodeDeclarations ] 

[ nodeDeclarations , ] 
nodeDeclarations: 

nodeDeclaration 

nodeDeclaration , nodeDeclarations 
mfrotationValue: 

sfrotationValue 

[ ] 

[ sfrotationValues ] 

[ sfrotationValues , ] 
sfrotationValues: 

sfrotationValue 

sfrotationValue , sfrotationValues 
mfstringValue: 

sfstringValue 

[ ] 

[ sfstringValues ] 

[ sfstringValues , ] 
sfstringValues: 

sfstringValue 

sfstringValue , sfstringValues 
mfvec2fValue: 

sfvec2fValue 

ts 

[ sfvec2fValues ] 

[ sfvec2fValues , ] 
sfvec2fValues: 

sfvec2fValue 

sfvec2fValue , sfvec2fValues 
mfvec3fValue: 

sfvec3fValue 

[ ] 

[ sfvec3fValues ] 

[ sfvec3fValues , ] 
sfvec3fValues: 

sfvec3fValue 

sfvec3fValue , sfvec3fValues 


chapter seven 


Ther are many possible architectures for building multiuser 
worlds. Some systems will be based on a client/server model; 
others will be based on a peer-to-peer model, possibly using 
multicast communication; still others will find some middle 
ground. 

One of the goals of the Moving Worlds proposal is to provide 
the functionality needed to build these different models without 
dictating which approach should be used. All the likely models for 
multiuser worlds would use Moving Worlds features in the same 
Way. 

This chapter highlights the common requirements for all 
multiuser worlds and points out the parts of the Moving Worlds. 
proposal that address those requirements. An example demon- 
strates one possible implementation of a multiuser world. 
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General Approach 


There are two aspects to a shared multiuser world: 


1. Sharing the state of a world: whether the doors are open or 
closed; where movable objects are; starting animations simul- 
taneously; and so on. 

2. Exploring a world while seeing avatars representing the other 
people who are in the world at the same time. 


The second aspect is a special case of the first in that a special 
object—the user representation, or avatar—is shared among 
browsers viewing the world. This chapter discusses the specific 
case of shared avatars and then generalizes the functionality to 
support any shared item. 

The approach is the same for both the specific and general 
cases. One or more Script nodes are put into the world, each 
specifying either a general-purpose or an application-specific 
applet that carries out the network functionality. For each node 
containing shared information, either Routes are added between 
the appropriate events and the Script node, or the shared node 
itself is passed to the Script (which can then get and set the node’s 
fields). The former approach should be used when information is 
needed every time the relevant node changes; the latter should be 
used when shared information is needed only occasionally. 


Requirements for Supporting Multiuser Worlds 


To support shared multiuser worlds, the following basics are 
needed: 


A means to determine a user’s location in a world. 


The browser must make available the spatial location of the 
viewer relative to a known point, so that the scripts controlling the 
multiuser functionality can send this position to other browsers. 

A BoxProximitySensor can indicate where a user is relative to a 
specific frame of reference. This is useful when the location and 
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orientation are needed only for parts of the world, or if the world 
is segmented into Zones (see “A way of communicating the 
location to others” below) with one sensor for each. (A 
BoxProximitySensor can be attached to the world’s root Transform 
if it’s necessary to determine the viewer’s location anywhere in 
the world.) The user’s location can be accessed by routing events 
from the Sensor’s position and orientation fields, or by routing an 
SFNode for the sensor into the script and reading the fields when 
needed. 


A way to identify and describe the unique user. 


It must be possible to uniquely identify the users in the shared 
space in order to inform the server or the other browsers that are 
sending the location information. 

This information is application-specific. The application might 
require friendly nicknames, e-mail addresses, URLs of avatars, or 
something else entirely. Typically, user identification is handled by 
a script reading information from a configuration file. 


A way of communicating the location to others. 


After the spatial location is available, the script needs a means to 
send the information to other browsers or the server. 

The protocol used to do this depends on the application; for 
example, it could be VRML+ or DIS or VSCP. 

Moving Worlds supports such communication by allowing 
scripts to run asynchronously; any of the languages likely to be 
used for scripting have network functionality. A Java applet, for 
example, can use the standard Java threading mechanisms to 
spawn a thread that then uses Java’s network classes to send 
information to the network. Moving Worlds does not need any 
added API calls to provide this functionality. 


Support to receive and display location information about 
others. 


Browsers must be able to receive information over the network, 
either from a server or a peer, and use that information to update 
the shared scene. 
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In Moving Worlds, scripts use normal language constructs to 
handle application-dependent protocols. When a user first con- 
nects to a shared world, information about that user’s avatar is 
sent to other browsers sharing that world. This information 
typically includes a VRML description (or a URL toa VRML 
description) of the avatar. . 

The avatar can be put into the world in several ways. For 
example, one or more nodes can be placed in the world, in the 
same Transform as the BoxProximitySensor nodes. 

After the avatar is created, the receive-and-display script can 
provide an SFNode pointer to the avatar’s node(s) to allow other 
scripts to move the avatar around in the scene. 


A way to detect and propagate state changes. 


In the case of trying to share state information across the net- 
work—whether that information consists of a boolean indicating 
whether a light is lit, or the time an animation should start, or the 
position of a movable object—a script must be able to read and 
write this state. 

In Moving Worlds, this state-sharing is accomplished by routing 
events between the nodes to be shared and the script that is 
responsible for propagating the changes. 

A separate eventIn and eventOut (or a separate script) is pro- 
vided for every state that can change, so that it can be associated 
with a unique name before sending it over the network. 

One fix would be to support the userData field on Routes to 
allow you to use fan-in without losing the information as to which 
piece of state was being sent. 

As information is received off the network, the script can either 
send an event via a route to change the state, or can use the 
getValue() method to obtain the value of a field (if the script has 
an SFNode pointer to the portion of the scene graph being 
changed). 
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Pieces Left Out 


The goal of this chapter is to give potential users and 
implementors of Moving Worlds a feel for how multiuser systems 
can be built. One strength of the Moving Worlds proposal is, 
however, that it balances simplicity against flexibility. There are 
thus many interesting and important aspects of distributed sys- 
tems that this proposal makes no attempt to address. These areas 
are open, and the choice of how to solve them is left to the system 
builder. They include: 


Distributed synchronization 
Consistency 


Distributed naming 


Example 7-1: 


Separator { 

DEF bar BoxProximitySensor { } // To detect our own position 
DEF foo Separator { } // Avatars are added here 
} 
DEF baz Script { 

eventIn SFVec3f position 

eventIn SFRotation orientation 

field SFNode avatarRoot IS foo 

behavior "http://xyz.com/mynetworkprotocol. java" 

ROUTE bar.position -> baz.position 

ROUTE bar.orientation -> baz.orientation 


This example needs rewriting to match the final version of the 
API, but it should be close enough to give the general idea. 


class MyNetworkProtocol extends VRMLApplet implements 
Runnable { 

void start() { 

// spawn thread to monitor network 

} 

void eventIn(Event e) { 

// send position and orientation events to server 
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} 
void run { 
// monitors network, 
// on receipt of appropriate events from network calls 
// sends add, delete, change events to avatarRoot. 
} 
} 


Now that you have a strong sense of the major changes between 
VRML 1.0 and the Moving Worlds VRML 2.0 Specification, it is 
advantageous to illustrate those concepts with some specific 
applications designed by Silicon Graphics for that very purpose. 


Transforms and Leaves 


This example has two parts. First is an example of a simple VRML 
1.0 scene. It contains a red cone, a blue sphere, and a green cylin- 
der with a hierarchical transformation structure. Next is the same 
example using the Moving Worlds Transforms and Leaves syntax. 


VRML 1.0 


//VRML V1.0 ascii 
Separator { 
Transform { 
translation 0 2 0 
} 
Material { 
diffuseColor 1 0 0 
} 


Cone { } 


Separator { 

Transform { 
scaleFactor 2 2 2 

} 

Material { 
diffuseColor 0 0 1 

} 

Sphere { } 
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311” 


Transform { 
translation 2 0 0 

} 

Material { 
diffuseColor 0 1 0 

} 

Cylinder { } 


VRML 2.0 
//NRML V2.0 ascii 
Transform { 
translation 0 2 0 
children [ 
Shape { 
appearance Appearance { 
material Material { 
diffuseColor 1 0 0 
} 
} 
geometry Cone { } 


I, 


Transform { 
scaleFactor 2 2 2 
children [ 
Shape { 
appearance Appearance { 
material Material { 
diffuseColor 0 0 1 
} 
} 
geometry Sphere { } 
is 


Transform { 
translation 2 0 0 
children [ 
Shape { 
appearance Appearance { 
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material Material { 
diffuseColor 0 1 0 
} 
} 
geometry Cylinder { } 


Prototypes and Alternate Representations 


Moving Worlds has the capability to define new nodes. VRML 1.0 
had the capability to add nodes using the Fields field and isA 
keyword. The prototype feature can duplicate all the features of 
the 1.0 node definition capabilities, as well as the alternate repre- 
sentation feature proposed in the VRML 1.1 draft spec. Take the 
example of a RefractiveMaterial. This is just like a Material node 
but adds an indexOfRefraction field. This field can be ignored if 
the browser cannot render refraction. In VRML 1.0, this would be 
written as follows: 


RefractiveMaterial { 
fields [ SFColor ambientColor, MFColor diffuseColor, 
SFColor specularColor, MFColor emissiveColor, 
SFFloat shininess, MFFloat transparency, 
SFFloat indexOfRefraction, MFString isA ] 


isA "Material" 


} 


If the browser had been hardcoded to understand a 
RefractiveMaterial, the indexOfRefraction would be used; other- 
wise, it would be ignored and RefractiveMaterial would behave 
just like a Material node. 
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In VRML 2.0, this is written as follows: 


PROTO RefractiveMaterial [ 
field SFColor ambientColor 0 
field MFColor diffuseColor 0. 
field SFColor specularColor 0 
field MFColor emissiveColor 0 
field SFFloat shininess 0 
field MFFloat transparency 00 0 
field SFFloat indexOfRefraction 0.1 ] 


o1 © 
oOo Oo 


0.5 


{ 
Material { 

ambientColor IS ambientColor 
diffuseColor IS diffuseColor 
specularColor IS specularColor 
emissiveColor IS emissiveColor 
shininess IS shininess 
transparency IS transparency 


Although this is more wordy, notice that the default values are 
given in the prototype. These are different than the defaults for the 
standard Material, therefore allowing you to change defaults on a 
standard node. The EXTERNPROTO capability allows the use of 
alternative implementations of a node: 


EXTERNPROTO RefractiveMaterial [ 
field SFColor ambientColor 
field MFColor diffuseColor 
field SFColor specularColor 0 
field MFColor emissiveColor 0 
field SFFloat shininess 0 
field MFFloat transparency 000 
field SFFloat indexOfRefraction 0.1 ] 


05 
0 
0 


Oo Oo 


http: //www.myCompany.com/vrm1Nodes/RefractiveMaterial.wrl, 
http: //somewhere.else/MyRefractiveMaterial .wr] 
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This process will choose from one of three possible sources of 
RefractiveMaterial. If the browser has this node hardcoded, it will 
be used. Otherwise, the first URL will be requested and a proto- 
type of the node will used from there. If that fails, the second will 
be tried. 


Text in Other Languages 


Moving Worlds has a new Text node that allows the use of UTF8 
characters to display text in any language. For a few languages 
(such as Chinese), a language field is required to give a full speci- 
fication of the character set to use. Because this field is part of the 
Text node, the Chinese language would have to be set in every 
Text block in order for Chinese to be used throughout the file. The 
prototype feature solves this problem by allowing a custom 
ChineseText node to be defined. 


PROTO ChineseText [ field MSFString string "" ] 
{ 
Text { 
language "ch" 
direction TBRL 
string IS string 
} 
} 


Note that the default direction is set to be top to bottom for each 
string and right to left for consecutive strings, a common format 
for Chinese text. 


Shuttles and Pendulums 


Shuttles and pendulums are great building blocks for composing 
interesting animations. This shuttle translates its children back 
and forth along the X axis, from —1 to 1. The pendulum rotates its 
children about the Y axis, from 0 to 3.14159 radians and back 
again. 
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PROTO Shuttle [ 
field SFFloat rate 1 
eventIn SFBool moveRight 
eventOut SFBool isAtLeft 
field MFNode children ] 


DEF F Transform { children IS children } 
DEF T TimeSensor { cycleCount = -1 cycleInterval IS rate } 
DEF S Script { 

field SFBool right TRUE 

eventIn SFBool moveRight IS moveRight 

eventIn SFBool isActive 

eventOut SFBool isAtLeft IS isAtLeft 

eventOut SFBool up 

eventOut SFBool down 

eventOut SFTime start 

eventOut SFInt32 resetCount 


behavior "shuttle. java" 
} 
DEF I PositionInterpolator { 

keys [ 0, 1 ] 

values [ -100, 100 ] 
} 
ROUTE T.fraction TO I.set_fraction 
ROUTE I.outValue TO F.set_translation 
ROUTE T.isActive TO S.isActive 
ROUTE S.resetCount TO T.cycleCount 

} 


shuttle. java 


import "vrml.*" 


class Shuttle extends Script { 
SFBool right = (SFBool) getField("right"); 
SFBool isAtLeft = (SFBool) getEventOut("isAtLeft"); 
SFBool up = (SFBool) getEventOut("up"); 
SFBool down = (SFBool) getEventOut("down"); 
SFTime start = (SFTime) getEventOut("start"); 
SFInt32 resetCount = (SFInt32) getEventOut("resetCount" ); 
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public void moveRight(ConstSFBool value, SFTime ts) { 
if (value.getValue()) { 
// want to move Right 
up.setValue( TRUE); 
down.setValue(FALSE); 
start.setValue(ts.getValue()); 
} 
else { 
// want to move Left 
up.setValue(FALSE); 
down. setValue( TRUE); 
start.setValue(ts.getValue()); 
} 
} 


public void isActive(SFBool value, SFTime ts) { 
// if this is false (transitioned from active to 
// inactive) we can send our isAtLeft event 
if ('value.getValue()) { 
right.setValue(!right.getValue()); 
jisAtLeft.setValue(!right.getValue()); 
resetCount.setValue(1); // stop TimerSensor 
} 
} 
} 


PROTO Pendulum [ 
field SFFloat rate l 
eventIn SFBool moveCW 
eventOut SFBool isAtCCW 
field MFNode children ] 


DEF F Transform { children IS children } 
DEF T TimeSensor { cycleCount = -1 cycleInterval IS rate } 
DEF S Script { 

field SFBool CW TRUE 

eventIn SFBool moveCW IS moveCW 

eventIn SFBool isActive 

eventOut SFBool isAtCCW IS isAtCCW 

eventOut SFBool up 

eventOut SFBool down 

eventOut SFTime start 
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eventOut SFInt32 resetCount 


behavior "pendulum. java" 
} 
DEF I RotationInterpolator { 

keys [ 0, 1 ] 

values [ 0100, 010 3.14159 ] 
} 
ROUTE T.fraction TO I.set_fraction 
ROUTE I.outValue TO F.set_rotation 
ROUTE T.isActive TO S.isActive 
ROUTE S.resetCount TO T.cycleCount 

} 


pendulum. java 


import "vrml].*" 


class Pendulum extends Script { 
SFBool CW = (SFBool) getField("CW"); 
SFBool isAtCCW = (SFBool) getEventOut("isAtCCW"); 
SFBool up = (SFBool) getEventOut("up"); 
SFBool down = (SFBool) getEventOut("down"); 
SFTime start = (SFTime) getEventOut("start"); 
SFInt32 resetCount = (SFInt32) getEventOut("resetCount"); 


public void moveCW(ConstSFBool value, SFTime ts) { 
if (value.getValue()) { 
// want to move CW 
up.setValue( TRUE); 
down. setValue(FALSE); 
start.setValue(ts.getValue()); 
} 
else { 
// want to move CCW 
up.setValue(FALSE); 
down. setValue( TRUE); 
start.setValue(ts.getValue()); 
} 
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public void isActive(SFBool value, SFTime ts) { 
// if this is false (transitioned from active to inac- 
tive) 
// we can send our isAtCCW event 
if (!value.getValue()) { 
CW.setValue(!CW.getValue()); 
isAtCCW. setValue(!CW.getValue()); 
resetCount.setValue(1); // stop TimerSensor 
} 
} 
} 


In use, the Shuttle can have its isAtRight output wired to its 
moveLeft input to give a continuous shuttle. The Pendulum can 
have its isAtCCW output wired to its moveCW input to give a 
continuous Pendulum effect. Note that the initial value of 
TimeSensor.cycleCount is —1. This causes the TimeSensor to start 
immediately. CycleCount is set to 1 after the first cycle to take 
control of the TimeSensor. 


Robot 


Robots are very popular in VRML discussion groups. Here is a 
simple implementation of one. This robot has very simple body 
parts: a cube for his head, a sphere for his body, and cylinders for 
arms (he hovers, so he has no feet!). He is something of a sentry: 
he walks forward, turns around, and walks back, forever. This 
makes liberal use of the Shuttle and Pendulum described previ- 
ously. 


DEF Walk Shuttle { 
rate 10 
children [ 
DEF Turn Pendulum { 
children [ 
// The Robot 
Shape { 
geometry Cube { } // head 

} 


Transform { 
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scaleFactor 15 1 
translation 0 -5 0 
children [ Shape { geometry Sphere { } } ] // body 
iz 
DEF Arm Pendulum { 
children [ 
Transform { 
scaleFactor 1 7 1 
translation 1 -5 0 
children [ 
Shape { geometry Cylinder { } } 
] 
} 
] 
Y; 


// duplicate arm on other side and flip so it swings 
// in opposition 
Transform { 

rotation 0 1 0 3.14159 

translation 10 0 0 

children [ USE Arm ] 


//nook up the sentry. The arms will swing infinitely. He walks 
//along the shuttle path, then turns, then walks back, etc. 
ROUTE Arm.isAtCCW TO Arm.moveCW 

ROUTE Walk.isAtLeft TO Turn.moveCW 

ROUTE Turn.isAtCCW TO Walk.moveRight 
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A Better WWWaAnchor 


The Moving Worlds definition of WWWAnchor does not have the 
map field from VRML 1.0. This is because this field was of limited 
value. The 1.0 map field tried to duplicate the imagemap facility of 
HTML. But what was really needed was the texture coordinate. 
Moving Worlds can fix this with this PROTO for a better 
WWWaAntchor. This also adds the target field, which has been so 
popular lately. 


PROTO TextureAnchor [ 
field SFString name "" 
field SFString target "" 
field MFNode children [ ] 
{ 
Group { 
children [ 
DEF CS ClickSensor { }, 
Group { 
children IS children 
} 
] 
} 


DEF S Script { 
field SFString name IS name 
field SFString target IS target 
eventIn SFVec2f hitTexCoord 


behavior "TextureAnchor. java" 


ROUTE CS.hitTexCoord TO S.hitTexCoord 


TextureAnchor. java 


import "vrml1.*" 
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class TextureAnchor extends Script { 
SFString name = (SFString) getField("name" ); 
SFString target = (SFString) getField("target"); 


public void hitTexCoord(ConstSFVec2f value, SFTime ts) { 
// construct the string 
String str: 
sprintf(str, "%s?%g,%g target=%s", 
name.getValue(), 
value.getValue()[0], 
value.getValue()[1], 
target.getValue()); 


Browser. ]oadURL(str); 


Here is a simple example of how to do simple animation triggered 
by a click sensor. It uses an EXTERNPROTO to include a Rotor 
node from the net that will do the actual animation. 


EXTERNPROTO Rotor [ 
eventIn MFFloat Spin 
field MFNode children ] 
"http: //somewhere/Rotor.wrl"//Where to look for implementation 


PROTO Chopper [ 
field SFFloat maxAltitude 30 
field SFFloat rotorSpeed 1 ] 
{ 
Group { 
children [ 
DEF CLICK ClickSensor { }, // Gotta get click events 
Shape { ... body... }, 
DEF Top Rotor { ... geometry ... }, 
DEF Back Rotor { ... geometry ... } 
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DEF SCRIPT Script { 
eventIn SFBool startOrStopEngines 
field maxAltitude IS maxAltitude 
field rotorSpeed IS rotorSpeed 
field SFNode topRotor USE Top 
field SFNode backRotor USE Back 


scriptlType "java" 
behavior "chopper. java" 


} 


ROUTE CLICK.isActive -> SCRIPT.startOrStopEngines 
} 


DEF MyScene Group { 
DEF MikesChopper Chopper { maxAltitude 40 } 
} 


chopper. java: 


import "vrml.*" 


public class Chopper extends Script { 
SFNode TopRotor = (SFNode) getField("topRotor" ); 
SFNode BackRotor = (SFNode) getField("backRotor"); 


float fRotorSpeed = ((SFFloat) 
getField("rotorSpeed")).getValue(); 


boolean bEngineStarted = FALSE; 


public void startOrStopEngines(ConstSFBool value, SFTime 
ts) { 
boolean val = value.getValue(); 


// Don't do anything on mouse-down: 
if (val == FALSE) return; 


// Otherwise, start or stop engines: 
if (bEngineStarted == FALSE) { 
StartEngine( ); 
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} 
else { 
StopEngine(); 
} 
} 


public void SpinRotors(fInRotorSpeed, fSeconds) { 
MFFloat rotorParams ; 
float[] rp = rotorParams.getValue(); 


rp[0] = 0; 
rpLl] = fInRotorSpeed; 
rpl2] = 0; 


rp[3] = fSeconds; 
TopRotor.postEventIn("Spin", rotorParams); 


rp[0] = fInRotorSpeed; 

rpLl] = 0; 

rpl2] = 0; 

rp[3] = fSeconds; 
BackRotor.postEventIn("Spin", rotorParams ); 


} 


public void StartEngine() { 
//Sound could be done either by controlling a PointSound 
//node (put into another SFNode field) OR by adding/removing 
//a PointSound from the Separator (in which case the 
//Separator would need to be passed in an SFNode field). 


SpinRotors(fRotorSpeed, 3); 
bEngineStarted = TRUE; 
} 


public void StopEngine() { 
SpinRotors(0, 6); 
bEngineStarted = FALSE; 
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Guided Tour 


Moving Worlds has great facilities to put the viewer’s camera 
under control of a script. This is useful for things such as guided 
tours, merry-go-round rides, and transportation devices such as 
busses and elevators. The next two examples show a couple of 
ways to use this feature. 

The first example is a simple guided tour through the world. 
Upon entry, a guide orb hovers in front of you. Click on this and 
your tour through the world begins. The orb follows you around 
on your tour. Perhaps a PointSound node can be embedded inside 
to point out the sights. 


Group { 
children [ 
<geometry for the world>, 


DEF GuideTransform Transform { 
children [ 
DEF TourGuide Viewpoint { }, 
DEF StartTour ClickSensor { }, 
Shape { geometry Sphere { } }, // the guide orb 
] 
} 
] 
} 


DEF GuidePI PositionInterpolator { 
keys [ ... ] 
values [ ... ] 


} 


DEF GuideRI RotationInterpolator { 
keys [ ... ] 
values [ ... ] 


} 
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DEF TS TimeSensor { cycleInterval 60 } // 60 second tour 


DEF S Script { 
field SFNode viewpoint USE TourGuide 
eventIn SFBool active 
eventIn SFBool done 
eventOut SFTime start 
behavior "GuidedTour. java" 


} 


ROUTE StartTour.isActive TO S.active 

ROUTE S.start TO TS.startTime 

ROUTE TS.isActive TO S.done 

ROUTE TS.fraction TO GuidePI.set_fraction 

ROUTE TS.fraction TO GuideRI.set_fraction 

ROUTE GuidePI.outValue TO GuideTransform.set_translation 
ROUTE GuideRI.outValue TO GuideTransform.set_rotation 


GuidedTour. java: 

import "vrml].*" 

<Compute 

public class GuidedTour extends Script { 
SFTime start = (SFTime) getEventOut("start"); 
SFNode viewpoint = (SFNode) getField("viewpoint"); 


public void active(ConstSFBool value, SFTime ts) { 
if (value.getValue()) { // start tour 
Browser ..bindViewpoint( viewpoint. getValue()); 
start.setValue(ts.getValue()); 
} 
} 


public void done(ConstSFBool value, SFTime ts) { 
if (!value.getValue()) { // end tour 
Browser .unbindViewpoint(); 
} 
} 
} 
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Elevator 


Here is another example of animating the camera. This time, it is 
an elevator to ease access to a multistory building. For this ex- 
ample, I show a two-storied building and assume that the elevator 
is already at the ground floor. To go up, you just step inside. A 
BoxProximitySensor fires and starts the elevator up automatically. 
I leave call buttons for outside the elevator, elevator doors, and 
floor selector buttons as an exercise for the reader! 


Group { 
children [ 


DEF ETransform Transform { 
children [ 
DEF EViewpoint Viewpoint { }, 
DEF EProximity BoxProximitySensor { size 2 2 2 }, 
<geometry for the elevator, 
a unit cube about the origin with a doorway>, 
] 
} 
] 
} 


DEF ElevatorPI PositionInterpolator { 

keys [ 0, 1 ] 

values [ 000, 040] // a floor is 4 meters high 
} 


DEF TS TimeSensor { cycleInterval 10 } // 10 second travel 
time 


DEF S Script { 
field SFNode viewpoint USE EViewpoint 
eventIn SFBool active 
eventIn SFBool done 
eventOut SFTime start 
behavior "Elevator. java" 
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ROUTE EProximity.isActive TO S.active 

ROUTE S.start TO TS.startTime 

ROUTE TS.isActive TO S.done 

ROUTE TS.fraction TO ElevatorPI.set_fraction 

ROUTE ElevatorPI.outValue TO ETransform.set_translation 


Elevator. java: 


import "vrml.*" 


public class Elevator extends Script { 
SFTime start = (SFTime) getEventOut("start"); 
SFNode viewpoint = (SFNode) getField("viewpoint"); 


public void active(ConstSFBool value, SFTime ts) { 
if (value.getValue()) { // start elevator 
Browser .bindViewpoint(viewpoint.getValue()); 
start.setValue(ts.getValue()); 
} 
} 


public void done(ConstSFBool value, SFTime ts) { 
if (!value.getValue()) { // end tour 
Browser .unbindViewpoint(); 
} 
} 
} 
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Moving On 


By now, your grasp of the technical intricacies of the Moving 
Worlds standard is as complete as it can be at this stage of devel- 
opment. Doubtless your head is already swimming with potential 
applications of the technology. For that reason, the focus of the 
final chapter of this book moves away from specifics and back to 
the broader creative issues of Web design. I do not address every 
possible application of Moving Worlds in this treatment, however. 
Rather, my goal is to present many possible uses of the language 
over a broad variety of disciplines and, in doing so, inspire you to 
make even more connections and join the next wave to redefine 
the capabilities and services of the Internet. It is, after all, a com- 
munity for all of us, isn’t it? 


chapter eight 


. the first chapter of this book, you were shown how Moving 

Worlds is really nothing more than a tool. An elaborate and pow- 
erful tool, to be sure, but incapable of performing its function 
without the aid of a skilled artisan to wield it. The other chapters 
have all focused on providing you with an understanding of the 
technical underpinning of Moving Worlds, most specifically with 
how it differs from earlier versions of VRML, but that knowledge 
alone is insufficient to complete the creative process. 

The creative process occurs in several steps, many of which 
must be accomplished before any actual programming begins, and 
many of which involve business issues as well if you intend to 
complete a design for commercial purposes. The focus of the first 
part of this chapter is to give you an overview of the creative 
process of software design so that a proper foundation is laid for 
every application that you wish to create with Moving Worlds. 

Some of the latter sections of the chapter are more esoteric, 
dealing mainly with implications for social change as we collec- 

‘tively alter the Internet via its next evolutionary step. The 
glimpses into the global society of tomorrow may seem inspira- 
tional or frightening, depending on your perspective, but the type 
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of reaction that you have is less important than the fact that you 
have one. Why? Because, once again, the objective is to encourage 
your creativity. After all, you may well be the only individual 
among us with exactly the right background and experience to 
solve the next big stumbling block to come our way. If you are 
looking behind instead of ahead, you won’t see it coming. 

Before I dive into design and development wholeheartedly, 
please indulge me just a bit longer on the importance of being 
creative in everything you do. It is the wellspring of growth and 
progress in our personal and professional lives. Others have stated 
it far better than I, and it would not harm you to tack one or more 
of these quotes over your desk while designing your applications: 


“Don’t think! Thinking is the enemy of creativity. It’s self- 
conscious, and anything self-conscious is lousy. You can’t try 
to do things; you simply must do them.” 

—Ray Bradbury 


“Creative minds have always been known to survive any kind 
of bad training.” 
—Anna Freud 


“Man unites himself with the world in the process of creation.” 
—Erich Fromm 


“We are traditionally rather proud of ourselves for having 
slipped creative work in there between the domestic chores 
and obligations. I’m not sure we deserve such a big A-plus for 
all that.” 

—Toni Morrison 


“A creative artist works on his next composition because he 
was not satisfied with the previous one.” 
—Dmitry Shostakovich 


“The art of creation is older than the art of killing.” 
—Andrey Voznesensky 
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The Concept 


All applications must begin with that simple universal spark of 
inspiration known as an idea. We have ideas every day, but doz- 
ens more are dismissed than are acted upon. Others are retained 
and filed away until something sparks their resurgence to our 
consciousness. Indeed, the mere act of returning the idea to con- 
sciousness is often sufficient to upgrade it to a good idea. But a 
good idea is still far removed from a concept. 

Random House defines a concept as “an idea of something 
formed by mentally combining all of its characteristics or particu- 
lars, a construct.” With this definition, it should be readily appar- 
ent that few, if any, ideas materialize in our heads as fully devel- 
oped constructs, or concepts from which we may begin to design. 
With that in mind, let’s dissect the development of one concept 
from a raw idea to understand the process more clearly. 


The Initial Idea 


Most ideas spring from situations that illustrate their need. Sup- 
pose that you are being forced by your job or some other circum- 
stance to relocate to a new area that you know nothing about. 
Learning as much about that area as you can before you get there 
becomes one of your consuming pastimes. Perhaps you go to the 
library to research the town, or subscribe to the local newspaper to 
check on housing availability. Or, if you’re lucky, maybe the town 
has a Web site that can be helpful. All these resources are well and 
good, but they just don’t convey a sense of “being there,” and 
telling much about a house from the pictures in real estate maga- 
zines or, worse, from descriptions like the following is difficult: 


3BR/2BA nestled in a secluded glade just 2 minutes from the 
Santa Monica Expressway. Easy commute, quiet neighbor- 
hood. Zoned for Business also. Luxury skylight, gourmet 
kitchen, spacious master bedroom suite with custom panel- 
ing, private from the rest of the house. Must see to believe. 
$192,000. 
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Short of actually visiting this house, sorting out the mixed 
messages of the real estate listing would be almost impossible—or 
would it? Hey, I have an idea: What if someone could visit the 
house virtually, even walk through it, without ever leaving his or 
her home or another Realtor’s office 3,000 miles away? On the 
surface, that’s a really cool idea, but how do you noodle it out 
until it becomes a focused concept? Further, how can this concept 
be so concise and compelling that it will catalyze the birth of 
something no one has ever done before (in this instance, develop- 
ment of a virtual real estate market)? 


Combining the Characteristics and Particulars 


The definition of a concept previously adopted would lead you to 
believe that this portion of the process is a single step. That is one 
of the problems of definitions: they tend to simplify things to the 
lowest common denominator to gain the broadest possible under- 
standing of the term being defined. In reality, we go through many 
steps on the route from an idea to a concept. 


Defining the Audience 

Who is the target of the idea, and why would they be interested in 
it? Establishing some interest other than your own, even if it is 
only a niche interest, accomplishes two purposes: it allows you to 
move to the design stage with a broader perspective, and it per- 
mits you to gauge whether the amount of effort required to com- 
plete the project has hopes of bringing the expected return. 

The smaller the audience, the easier it is to establish what the 
audience is looking for and to determine the expected return. For 
example, as anew Moving Worlds programmer, you might simply 
want to prove to yourself that you can create a simple, one-room 
environment with a chair that visitors can sit in, a light they can 
turn on, and a silly robot dog to greet them when they come 
“home.” After you have done so, you have accomplished what 
you believe the audience was looking for, and the expected return 
is personal satisfaction. If you subsequently decide to show your 
creation to your friends, the expected return is to obtain their 
praise, support, and encouragement to do even more. These are 
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very simplistic motivations, even though the particular task that 
you choose to accomplish in these circumstances may not be 
simple for you to complete. 

Another example of a small targeted audience for a given 
application might be that of a student creating a specific environ- 
ment as part of an exercise. In such a situation, the audience to 
satisfy is governed by the professor but may consist of fellow 
students as well. Their expectations are very clear-cut, as are 
yours. Most of the time, you will not enjoy the luxury of such a 
narrow focus or such low expectations, however, so let’s return to 
something a little more thought provoking. The potential audience 
for a virtual real estate market is global, which makes your task 
that much more difficult. 


Listing the Needs of the Audience 

Before you can begin to design something for the chosen audience, 
you must first ensure that you have established the needs of that 
audience without falling into the trap of assumption. Assuming that 
you already know the needs of an audience as broad as the one | 
have outlined virtually assures your failure. You will design 
something that serves your needs very well, but your design will 
do absolutely nothing to meet any needs of your audience that 
don’t happen to coincide with your own. So, how do you best learn 
the needs of the members of your audience? Simple. Ask them. 

Do the broadest possible survey that time and resources allow of 
what the audience would expect from the concept that you have 
envisioned. By now, you should have surmised that that was 
exactly the process followed in developing the specification for 
Moving Worlds itself. The VAG solicited proposals from any 
potential contributor who wished to step forward. After all the 
proposals were in, a prolonged period of discussion and debate 
began, during which many of the needs of the established VRML 
audience were weighed against the design possibilities. After- 
ward, the participants were surveyed to determine which pro- 
posal best served the needs of the entire audience. Although this 
example mixes the concept and design stages from the pure model 
being established herein, it does illustrate the importance of taking 
the needs of the audience into consideration in the development of 
any concept. 
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Returning to the real estate idea, begin by brainstorming all of 
the possible needs that you can imagine beyond your own. Resist- 
ing the temptation to edit yourself during this process is impor- 
tant. Let the audience weed out the weak and superfluous ideas as 
part of the survey process. Now, assume that you have surveyed 
500 potential clients of such a service via the Internet. From a list 
of 30 choices, you obtained the following top-ten answers (the 
other 20 choices scored a response of under 50 percent and are not 
listed here): 


I feel that houses so viewed must contain the following to 
satisfy my needs: 


1. Known damage and normal wear and tear must be visible. 
(99%) 
. Must be able to view every room from any angle. (96%) 
. Interior fixtures must be precisely to scale. (92%) 
. Exterior appearance and landscaping must be present. (84%) 
. Ambient sounds of the surrounding area must be accurate. 
(82%) 
6. Existing color schemes must be accurate. (79%) 
7. | want the tour to be guided by an agent to answer my ques- 
tions. (75%) 
8. Must be able to change color schemes from a palette of 
choices. (65%) 
9. I want to be able to place and move furniture in the environ- 
ment. (62%) 
10. Must be able to view the interior under varied lighting condi- 
tions. (55%) 


To be successful, your concept must take the most sought-after 
features into account. Based on what you have learned about 
audience needs, it is now time to assimilate and consolidate those 
needs into a single cohesive concept—a mission statement, if you 
will, which puts the original idea into context. 


oF WN 


Define the Mission 

So, now you've thought things through, initially at least, and 
received some feedback on your original idea. A good concept 
proposal seeks the common ground of all your forethought and 
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states it in a manner that readily conveys the power of the idea to 
others. Even if your concept is not intended for commercial pur- 
poses, you should couch it in language that will sell the concept 
to the reader. In this instance, the concept is best stated by the 
following: 


Proposal: To design a user-friendly application that will 
replicate physical structures in detail on the Internet for 
potential buyers of those properties, thereby expanding the 
influence of real estate marketing beyond traditional geo- 
graphic boundaries. 


Why is this specific wording so important? Because the commu- 
nity most likely to fund the proposal for development is the same 
group that stands to gain the greatest benefit: the Realtors them- 
selves. Granted, customers of the service are the real audience that 
must be supported, but those are the same customers the Realtors 
are trying to serve, along with the demand side of the economic 
equation. You are proposing a service to supply, so you must 
either supply that service alone (which would be nearly impos- 
sible in this example) or in conjunction with another service 
provider in the targeted group who sees the value of the concept 
(again, the Realtors). 


Define the Benefits 
Having a clearly stated proposal is not enough, however, when 
you are asking others to invest in your dream with time, money, 
other resources, or all of these. You must also show them their 
benefits from the investment. To do that, you must demonstrate 
that your concept not only can be pursued, but should be pursued. 
In the early stages of a proposed project, investors are much less 
interested in how something is done than with what they stand to 
gain should it be done, and done correctly. Therefore, keep any 
design specifics that you might have determined already out of 
the initial proposal. The specifics are introduced during the next 
round of development, which will be discussed shortly. 
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In this example, the benefits to the investors are outlined as 
follows: 


Tangible Benefits 


WS The project creates an increased customer base upon which 
to draw, thereby increasing the chances of quickly “match- 
ing” a listing to a customer. 


“* Customers can screen house listings and actually decide to 
visit many fewer homes prior to purchase, thereby shorten- 
ing the purchase cycle and also minimizing employee 
“dead time” spent shuttling customers to many locations. 


~~ Inan open market, shorter purchase cycles create the 
potential for higher-volume sales. 


WS More efficient use of employee time reduces overhead 
costs. 


Intangible Benefits 


Ws The program would enhance customer satisfaction by 
making the home purchase process simpler and more 
efficient. 


By being the first to offer this service, investors would have 
an advantage over competitors who attempt to enter the 
market after it is established. 


Always separate benefits into the tangible and intangible 
categories for quick reference by targets of the proposal. Take your 
time and think these through fully, as you must view each poten- 
tial investor as the only hope you have of seeing your program 
come to fruition. Even if that really isn’t the case, you will be 
much more successful if you approach things in this fashion. 

So, you've formulated a solid concept proposal and presented it 
successfully. What’s next? Don’t expect a check to begin program- 
ming just yet; now, you must produce a design specification. 
Generally, you will receive some minimal funding from the inves- 
tors for your time to produce this document, and after it is done, 
any savvy investor will have an expert go over it with a fine-tooth 
comb as part of the investor’s due diligence process. 
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Even if you are working on a concept for noncommercial 
purposes, producing a design specification is still the next logical 
step. Otherwise, you have no blueprint for development—a lack 
which, as a rule, leads to chaos, confusion, and eventual failure on 
all but the smallest of programming tasks. 

In either case, the hard work to realize your dream is just 
beginning. 


The Design Specification 


The structure of a design specification for an application differs 
somewhat from that for an original program. For example, creat- 
ing an end-user-friendly interface is the critical issue when design- 
ing an original program. Because you are designing an application 
of Moving Worlds, that issue already has been taken care of for 
you. End users will access your world through a Moving Worlds-— 
compliant browser just as millions of users now access HTML 
documents through compatible browsers such as Netscape Navi- 
gator, Mosaic, and many others. 

Even though the browser will make the interface transparent to 
the end user, in the example that I have chosen you must still 
provide some interface for those people who will input the param- 
eters of individual homes. Ideally, the application will accept 
standard room dimensions as they would normally appear in a 
real estate listing (for example, LR 16 X 21), in conjunction with 
some form of alphanumeric spatial notation so that individual 
rooms are arranged properly within the overall structure. 

Also, you want to create libraries of objects, such as fireplace 
mantels, banisters, shrubs, trees, and so on, so that agents listing a 
new home need do nothing more than point and click their way 
through a series of choices to create reasonable facsimiles of the 
actual homes. 

Some of these object libraries, such as lighting, doors, and 
windows, for example, will contain behaviors as well. Again, this 
precludes the need for real estate agents to have any program- 
ming background to use the application and make it interactive. In 
essence, the application that I have been defining would provide 
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the same service to Moving Worlds design as C++ object libraries 
did for non-Internet-specific programming. Wow, that’s a fairly 
huge undertaking, and perhaps that realization makes the concept 
much less appealing than it seemed originally. Still willing to give 
it a shot? Go visit a major home improvement warehouse and 
think about cataloging and building every possible fixture type in 
the place, and then attributing exact behaviors to each of them as 
appropriate. As an individual, that is a daunting task to contem- 
plate. But what if you were one member of a 20-person team? Or 
what if 65 percent of the objects that you needed were already 
available in the public domain, coded and ready to go? 

Okay, so maybe you aren’t discouraged to the point that you are 
willing to scrap the whole idea. Either choice is irrelevant to my 
real point: by forcing yourself to think through design issues, you 
have gained a much clearer perspective on what resources are 
needed to accomplish the project. Revisit all the audience needs 
that you learned as part of the concept development process and 
analyze each one of them equally in detail. After you have done 
so, you will have the core of a design specification in outline form, 
and this is what you must develop regardless of the type of project 
you envisioned in the beginning. 


The Development Process 


Software applications are nothing more than machines that pro- 
cess information. By thinking of them as machines, you begin to 
see parallels in the design and development processes with those 
of other types of machinery. The first step is the idea. The idea is 
developed into a concept proposal. After the concept is sound, it is 
used as the framework to create a specification. The specification 
is the blueprint of the machine that you are trying to build. The 
next step in the process, which is where you are now, is to build a 
working prototype. 

As with many things in life, the best way to approach this is to 
break it down into incremental steps. Your Moving Worlds appli- 
cation will likely contain many objects and behaviors, both inter- 
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active with and independent of one another. Treat each one ini- 
tially as an individual entity, much like the Elevator example 
provided in Chapter 7, “Examples and Extensions of Moving 
Worlds.” Build the single component (or subroutine, if thinking of 
it that way is easier) and tinker with the component until it does 
what you want it to do. 

As other individual entities are created, you must integrate 
them with existing subroutines to form the society of your Moving 
Worlds environment. The greater the number of objects and 
behaviors being modeled, the more complex the society. As societ- 
ies become more complex, the potential number of interactions 
between the inhabitants increases exponentially, as does the level 
of tinkering and quality assurance that you must perform. It 
sounds deceptively simple on the surface, but development cycles 
get out of hand and overrun original projections more often than 
not, even among veteran programming teams. 

If you understand the creative process outlined at the beginning 
of this chapter, you will understand why most products exceed 
their original development cycles as well. Designers view each 
project as one of their children, and willingly continue to perfect 
that child until circumstances force the apron strings to be cut. 
Elimination of crash bugs and fatal errors aside, the law of dimin- 
ishing returns comes into play in every development cycle. You 
must learn to recognize this point and not fall into the trap of 
doting over a “finished” application so much that you are unwill- 
ing to begin the next project. There are so many of them out there 
awaiting your attention. 


Placing it All in Perspective 


Several themes have been introduced previously that require 
reiteration at this point: 


Technology does not exist for its own sake. Rather, each 
advance or evolutionary outgrowth of prior technology 
must be viewed as a tool to change the way we collectively 
live, work, play, and thrive as a society. 
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The manner in which new advances are applied defines the 
path that we take as a society. 


Humankind is now poised on the brink of a third major 
social revolution, the Information Revolution, which will 
dramatically alter civilization once again. Moving Worlds 
has the potential to be one of the first catalysts of that 
change. 


Reality itself is nothing more than the arrangement of 
information in a specific order. Everything exists in three 
dimensions and is acted upon in a fourth dimension, which 
is time. 

Most of the western world is in a service-based economy 
that has stemmed from the technological revolution. 


The most important tool sets in service-based economies 
are information management tools. 


The Internet is a community, and all communities benefit 
from the diversity and individuality of their inhabitants. 


The greater the ease with which a community may be 
joined, the broader and more diverse its membership will 
become. 


Moving Worlds offers a tremendous ability to present 
information spatially over time and directly involve the 
user in the manipulation of that information. 


If you follow this progression of facts, you cannot help but have 
a clear understanding of the overall impact of Moving Worlds. To 
place it in perspective with the evolution of the Internet broached 
in Chapter 2, “The Evolution of Internet Programming,” and 
thereby discern the greater implications, let’s now examine three 
key concepts advanced by other authors and analysts. 


Mirror Worlds 


In 1992, the Oxford Press published an incredible treatise on the 
long-term potential of the information revolution titled Mirror 
Worlds or: The Day Software Puts the Universe in a Shoebox .. . How it 
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Will Happen and What it Will Mean. The author, David Gelernter, is 
an associate professor of computer science at Yale University and 
an expert in programming languages and methods and in artificial 
intelligence. Gelernter explains the importance of Mirror Worlds 
as follows: 


Software today offers assistance to the specialist (in every- 
body)—not to the citizen. The mere citizen deals with the 
increasingly perilous complexity of his government, business, 
transportation, health, school, university and legal systems 
unaided. Mirror Worlds represent one attempt to change this 
state of affairs. 

You set up a software mirror wherever you like, then allow 
some real-world systems to unfold before it. The software 
faithfully reflects whatever is going on out front. But this is a 
three dimensional kind of reflection: The program reaches out 
and engulfs some chunk of reality.... A hospital Mirror World 
has a software version of every patient, doctor, bed, room— 
and every abstract entity that’s important: cash in the bank, 
drugs on order and so on.... The organization’s current status 
is presented in the form of an intricate and constantly chang- 
ing picture that you explore from your computer screen, 
skimming the surface or diving deeper as you like. 

What's the point? These Mirror Worlds are like regular old 
fashioned databases, to some extent. If you need to find 
Shmoe’s salary or Schwartz's social security number, you can 
look it up. But they go far beyond this. The Mirror World is 
directly accessible twenty-four hours a day, to the population 
that it tracks. You can parachute in your own software agents. 
They look out for your interests, or gather data that you need, 
or let you know when something significant appears to be 
going on. You consult the Mirror World like an encyclopedia 
when you need information; you read it like a dashboard 
when you need a fast take on current status. Fundamentally, 
these programs are intended to help you comprehend the 
powerful, super-techno-glossy, dangerously complicated and 
basically indifferent man-made environments that enmesh you, 
and that control you to the extent that you don’t control them. 
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Gelernter’s worlds are not as farfetched as they might seem at 
first. The constructs that he envisions can be created from technol- 
ogy that either already exists or is well along in development. 
Mirror Worlds are not governed by a single program, however. 
Rather, they come to life via the interaction of many separate 
programs working in conjunction with one another in an arrange- 
ment that Gelernter refers to as an ensemble. 

Based on what you already know of Moving Worlds, what roles 
could it possibly play in the larger context of a Mirror World? Your 
first thought is likely the most obvious one: to visually represent 
the world in three dimensions; but there is more. How will inani- 
mate objects function in the Mirror World when Avatars or Agents 
interact with them, if not through Moving Worlds or some descen- 
dent of it? 


Web Objects 


Despite the well-hyped proliferation of the World Wide Web, in 
reality it remains a relatively primitive medium. As Steve G. 
Steinberg pointed out in the February 1996 issue of Wired magazine: 


On one side is the Web server, an idiot savant that responds 
to every request by sending out a hypertext document. On the 
other side is the Web client, a dumb terminal that simply 
displays documents and waits for mouse clicks. This is about 
to change.... 

The first stage involves making the client and server 
smarter. On the server side, this means linking Web sites to 
information stored in local databases and spreadsheets. On 
the client side, it requires making every application you use— 
not just your specialized web browser—able to access the Web. 

Things start to get much more interesting in the second 
stage. The client and server will begin to exchange not just 
data, but programs. These little applications, or applets, will 
allow for new, powerful kinds of interaction.... You'll no 
longer have to worry about whether you have the capability 
to display a new kind of data type because the “capability” 
will be sent to you with the file. 
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In the final stage, the distinction between clients and 
servers will begin to blur. Code will flow in both directions. A 
client might send a small program to the server to perform a 
specialized database search. Applets will begin to resemble 
agents—nomadic programs sent out to find and gather 
information. The Web will become fully animated, energized 
by the proliferation of tiny bits of code, powered by the 
intelligence of computers. 


These small programs are referred to as Web Objects. Each can 
be unique and individual, but the real power of Object technology 
stems from standardization, not individuality. Remember the C++ 
object libraries mentioned earlier? And what about the same 
dynamic in Moving Worlds? Do I need to create a better elevator, 
or can I use the object code that already replicates that function? 

And how do Web Objects relate back to the concept of Mirror 
Worlds? Well, every environment breaks down into discrete 
components, and these components overlap many possible Mirror 
Worlds. Why design them multiple times? The world has a finite 
number of them, and if we all just work together... 

This is the exciting and intimidating thought at the heart of Web 
Objects, Mirror Worlds, and Moving Worlds. We will all work 
together to program the face of the global network and, in that 
context, the factors that made our previous real estate example 
seem daunting to develop lose their capacity to intimidate. Also, 
in the not-too-distant future, expect someone to design the ultimate 
receptionist program, for example. It will be called Jean/Gene, 
and users can select the sex with which they prefer to interact. The 
survival of this Web Object will be determined no differently than 
with any other evolutionary programming choice in the history of 
the Internet. If it becomes popular with users and is widely 
adopted, it will survive. If not, it will fade away. But, on the Web 
of tomorrow, after it has been created and approved by popular 
acclamation, expect to find Jean/Gene greeting you whenever you 
visit any new area. In other words, the proliferation of good Web 
Objects will be much more pervasive, and this proliferation will 
occur much more rapidly than we ever experienced in program- 
ming for stand-alone machines. Understanding why the prolifera- 
tion process will accelerate so rapidly is the final piece of the 
equation you need to comprehend the full impact of what lies ahead. 
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A New Level of Connectivity 


Who among us has not complained about connectivity issues at 
one point or another? Yet think of how pleased we all would have 
been just five years ago with current access and transfer rates. Our 
needs rise to meet the level of capability, and the level of capabil- 
ity that we are on the verge of experiencing is staggering to 
comprehend: 


At the same time as the speed of global interaction is increas- 
ing, so is the complexity. In 1994 the worldwide telecommuni- 
cations network had a billion telephones. Yet this network, 
intricate as it might seem, represents only a minute fraction of 
the communications terminals in the brain, the trillions of 
synapses through which nerve cells interact. According to 
John McNulty, a British computer consultant, the global 
telecommunications network of 1975 was not more complex 
than a region of the brain the size of a pea. But overall data 
processing capability is doubling every two and a half years, 
and if this rate of increase is sustained, the global telecommu- 
nications network could equal the brain in complexity by the 
year 2000.... The changes that this will bring will be so great 
that their full impact may well be beyond our imagination. No 
longer will we perceive ourselves as isolated individuals; we 
will know ourselves to be a part of a rapidly integrating global 
network, the nerve cells of an awakening global brain. 


So states Peter Russel in The Global Brain Awakens: Our Next 
Evolutionary Leap. Other futurists, such as Alvin Toffler, have 
envisioned similar developments that will rock the structures of 
government, business, economics, education, and entertainment 
as we currently know them. Connectivity is the key, and broad- 
band fiber-optic connectivity to the home is coming before the end 
of the millennium. So is Moving Worlds, and you are part of the 
process that will change everything we have always known. 

Welcome to tomorrow! 


Appendix A 
Java Bindings for the VRML API 


fies appendix describes the Java classes and methods that 
allow scripts to interact with associated scenes. 


Language 


Java™ is a portable, interpreted, object-oriented programming 
language developed at Sun Microsystems. It’s likely to be the most 
common language supported by VRML browsers in Script nodes. 
A full description of Java is far beyond the scope of this appendix; 
see the Java Web site for more information. This appendix de- 
scribes only the Java bindings of the VRML API (the calls that 
allow the script ina VRML Script node to interact with the scene 
in the VRML file). 


Exposed Classes and Methods for Nodes and Fields 


Java classes for VRML are defined in the package vrml. (Package 
names are generally all lowercase, in deference to UNIX file 
system naming conventions.) 

The Field class extends Java’s Object class by default (when 
declared without an explicit superclass, as below); thus, Field has 
the full functionality of the Object class, including the getClass() 
method. The rest of the package defines a Const read-only class 
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for each VRML field type, with a getValue() method for each class; 
and another read/write class for each VRML field type, with both 
getValue() and setValue() methods for each class. 

Most of the setValue() methods are listed as throws exception, 
meaning that errors are possible—you may need to write excep- 
tion handlers (using Java’s catch() method) when you use those 
methods. Any method not listed as throws exception is guaran- 
teed to generate no exceptions. Each method that throws an 
exception is followed by a comment indicating what type of 
exception will be thrown. 


package vrml; 


Class Field { 


// 


// Read-only (constant) classes, one for each field type: 


if 


Class ConstSFBool extends Field { 
public boolean getValue(); 
} 


class ConstSFColor extends Field { 
public floatL] getValue(); 
} 


class ConstMFColor extends Field { 
public float[][] getValue(); 
} 


class ConstSFFloat extends Field { 
public float getValue(); 
} 


class ConstMFFloat extends Field { 
public float[] getValue(); 
} 


class ConstSFImage extends Field { 
public byte[] getValue(int[] dims); 
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} 


class ConstSFInt32 extends Field { 
public int getValue(); 
} 


class ConstMFInt32 extends Field { 
public int[] getValue(); 
} 


class ConstSFNode extends Field { 
public Node getValue(); 
} 


class ConstMFNode extends Field { 
public Node[] getValue(); 
} 


class ConstSFRotation extends Field { 
public float[] getValue(); 
} 


class ConstMFRotation extends Field { 
public floatL][] getValue(); 
} 


class ConstSFString extends Field { 
public String getValue(); 
} 


class ConstMFString extends Field { 
public StringL] getValue(); 
} 


class ConstSFVec2f extends Field { 
public floatL] getValue(); 
} 


class ConstMFVec2f extends Field { 
public floatL][] getValue(); 
} 


class ConstSFVec3f extends Field { 
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public float[] getValue(); 


Class ConstMFVec3f extends Field { 
public float[][] getValue(); 
} 


class ConstSFTime extends Field { 
public double getValue(); 


{i 
// And now the writable versions of the above classes: 


// 


class SFBool extends Field { 
public boolean getValue(); 
public void setValue(boolean value); 


class SFColor extends Field { 
public floatL] getValue(); 
public void setValue(floatL] value) 
throws ArrayIndexOutOfBoundsException; 


class MFColor extends Field { 
public floatLJ[] getValue(); 
public void setValue(floatL][] value) 
throws ArrayIndexOutOfBoundsException; 
public void setValue(ConstMFColor value); 
public void setlValue(int index, float[] value); 


} 


class SFFloat extends Field { 
public float getValue(); 
public void setValue(float value); 


} 


class MFFloat extends Field { 
public float[] getValue(); 
public void setValue(float[] value); 
public void setValue(ConstMFFloat value); 
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public void setlValue(int index, float value); 


} 


class SFImage extends Field { 
public byte[] getValue(int[] dims); 
public void setValue(byte[] data, int[] dims) 
throws ArrayIndexOutOfBoundsException; 
} 


// In Java, the int class is a 32-bit integer 
class SFInt32 extends Field { 

public int getValue(); 

public void setValue(int value); 


} 


class MFInt32 extends Field { 

public int[] getValue(); 

public void setValue(int[] value); 

public void setValue(ConstMFInt32 value); 
public void setlValue(int index, int value); 


} 


class SFNode extends Field { 
public Node getValue(); 
public void setValue(Node node); 


class MFNode extends Field { 
public Node[] getValue(); 
public void setValue(Node[] node); 
public void setValue(ConstMFNode node); 
public void setlValue(int index, Node node); 


} 


class SFRotation extends Field { 
public float[] getValue(); 
public void setValue(float[] value) 
throws ArrayIndexOutOfBoundsException; 
} 


class MFRotation extends Field { 
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public floatL][] getValue(); 
public void setValue(float[][] value) 
throws ArrayIndexOutOfBoundsException; 
public void setValue(ConstMFRotation value); 
public void setlValue(int index, float[] value); 


// In Java, the String class is a Unicode string 
class SFString extends Field { 

public String getValue(); 

public void setValue(String value); 


class MFString extends Field { 
public StringL] getValue(); 
public void setValue(String[] value); 
public void setValue(ConstMFString value); 
public void setlValue(int index, String value); 


} 


class SFTime extends Field { 
public double getValue(); 
public void setValue(double value); 


class SFVec2f extends Field { 
public floatL] getValue(); 
public void setValue(float[] value) 
throws ArrayIndexOutOfBoundsException; 


} 


class MFVec2f extends Field { 
public floatL][] getValue(); 
public void setValue(float[J[] value) 
throws ArrayIndexOutOfBoundsException; 
public void setValue(ConstMFVec2f value); 
public void setlValue(int index, float[] value); 


} 
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class SFVec3f extends Field { 
public floatL] getValue(); 
public void setValue(floatL] value) 
throws ArrayIndexOutOfBoundsException; 
} 


class MFVec3f extends Field { 
public floatL][] getValue(); 
public void setValue(float[J[] value) 
throws ArrayIndexOutOfBoundsException; 
public void setValue(ConstMFVec3f value); 
public void setlValue(int index, float[] value); 


// 


// Interfaces (abstract classes that your classes can inherit 
// from but that you can't instantiate) relating to events 
// and nodes: 


interface EventIn { 
public String getName(); 
public SFTime getTimeStamp(); 
public ConstField getValue(); 
} 


interface Node { 
public ConstField getValue(String fieldName) 
throws InvalidFieldException; 
public void postEventIn(String eventName, Field eventValue) 
throws InvalideEventInException; 


} 


// 

// This is the general Script class, to be subclassed by all 
// scripts.Note that the provided methods allow the script 
// author to explicitly throw tailored exceptions in case 
// something goes wrong in the script; thus, the exception 
// codes for those exceptions are to be determined by the 
// script author. 
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class Script implements Node { 
public void processEvents(Events [] events) 
throws Exception; // Script:code is up to script author 
public void eventsProcessed( ) 
throws Exception; // Script:code is up to script author 
protected Field getEventOut(String eventName) 
throws InvalidEventOutException; 
protected Field getField(String fieldName) 
throws InvalidFieldException; 


Browser Interface 


This section lists the public Java interfaces to the Browser class, 
which allows scripts to get and set browser information. For 
descriptions of the methods, see the “Browser Interface” section of 
the “Scripting” section of the spec. 


public class Browser { 


public static String getName(); 
public static String getVersion(); 


public static String getNavigationType( ); 
public static void setNavigationType(String type) 
throws InvalidNavigationTypeException; 


public static float getNavigationSpeed(); 
public static void setNavigationSpeed(float speed); 


public static float getCurrentSpeed( ); 


public static float getNavigationScale(); 
public static void setNavigationScale(float scale); 


public static boolean getHeadlight(); 
public static void setHeadlight(boolean onOff); 


public static String getWor1dURL(); 
public static void loadWorld(String [] url); 
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public static float getCurrentFrameRate( ); 


public static Node createVrmlFromURL(String[] url) 
throws InvalidVRMLException; 

public static Node createVrmlFromString(String vrmlSyntax) 
throws InvalidVRMLException; 


public void addRoute(Node fromNode, String fromEventOut, 
Node toNode, String toEventIn) 
throws InvalidRouteException; 

public void deleteRoute(Node fromNode, String fromEventOut, 
Node toNode, String toEventIn) 
throws InvalidRouteException; 


public void bindBackground(Node background); 
public void unbindBackground( ); 
public boolean isBackgroundBound(Node background); 


public void bindNavigationInfo(Node navigationInfo); 
public void unbindNavigationInfo(); 
public boolean isNavigationInfoBound(Node navigationInfo); 


public void bindViewpoint(Node viewpoint); 


public void unbindViewpoint(); 
public boolean isViewpointBound(Node viewpoint); 


System and Networking Libraries 


To perform system or networking calls, use the appropriate 
standard Java libraries. 


Example: 
Here’s an example of a Script node which determines whether a 
given color contains a lot of red. The Script node exposes a color 
field, an eventIn, and an eventOut: 
Script { 
field SFColor currentColor 0 0 0 
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eventIn SFColor colorIin 
eventOut SFBool isRed 


scriptlype "javabc" 
behavior "ExampleScript. java" 


And here’s the source code for the “ExampleScriptjava” file that 
gets called every time an eventIn is routed to the above Script node: 


import vrml; 
class ExampleScript extends Script { 


// Declare field(s) 
private SFColor currentColor = (SFColor) 
getField("currentColor"); 


// Declare eventOut field(s) 
private SFBool isRed = (SFBool) getEventOut("isRed"); 


public void colorIn(ConstSFColor newColor, ConstSFTime ts) 
{ 
// This method is called when a colorIn event is received 
currentColor.setValue(newColor.getValue()); 


public void eventsProcessed() { 
if (currentColor.getValue()[0] >= 0.5) 
// if red is at or above 50% 
isRed.setValue(TRUE) ; 


For details on when the methods defined in ExampleScript are 
called, see the “Execution Model” section of Chapter 3, “Moving 
Worlds: The Proposal.” 


Appendix B 
( Bindings for the VRML API 


Ths appendix describes the C datatypes and functions that 
allow scripts to interact with associated scenes. 


Language 


VRML browsers aren’t required to support C in Script nodes. In 
fact, supporting C is problematic: 


WS Supporting C source code would require compiling and 
linking 
Supporting C object code would be platform-dependent 


Supporting any language without security features opens 
the door to allowing scripts to execute commands like 
“system(“rm -r /*”);”. 

Therefore, the bindings given in this document to provide 

interaction between VRML Script nodes and the rest of a VRML 
scene are provided for reference purposes only. 


Events In and Out (Prototyped Data Structures and Functions) 


/* 
* vrml.h - vrml support procedures for C 


*/ 
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typedef void * Field; 
typedef char * String; 
typedef int boolean; 


typedef struct { 
unsigned char *value; 
int dims[3]; 

} SFImageType; 


/* 

* Read-only (constant) type definitions, one for each field type: 
+/ 

typedef const boolean *ConstSFBool; 
typedef const float *ConstSFColor; 
typedef const float *ConstMFColor; 
typedef const float *ConstSFFloat; 
typedef const float *ConstMFF loat; 
typedef const SFImageType *ConstSFImage; 
typedef const int *ConstSF Int32; 
typedef const int *ConstMF Int32; 
typedef const Node *ConstSFNode; 
typedef const Node *ConstMFNode; 
typedef const float *ConstSFRotation; 
typedef const float *ConstMFRotation; 
typedef const String ConstSFString; 
typedef const String *ConstMF String; 
typedef const float *ConstSFVec2f ; 
typedef const float *ConstMF Vec2f ; 
typedef const float *ConstSFVec3Ff ; 
typedef const float *ConstME Vec3Ff ; 
typedef const double *ConstSFTime; 
/* 

* And now the writable versions of the above types:. */ 
typedef boolean *SFBool; 

typedef float *SFColor; 

typedef float *MFColor; 

typedef float *SFFloat; 


typedef float *MFFloat; 
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typedef SFImagelype *SF Image; 
typedef int *SF Int32; 
typedef int *MF Int32; 
typedef Node *SFNode; 
typedef Node *MFNode; 
typedef float *SFRotation; 
typedef float *MFRotation; 
typedef String SFString; 
typedef String *MF String; 
typedef float *SFVec2f ; 
typedef float *MFVec2f ; 
typedef float *SFVec3f ; 
typedef float *MFVec3f ; 
typedef double *SFTime; 
* 

* Event-related types and functions 

*/ 

typedef void *EventIn; 


String getEventInName(EventIn eventIn); 

int getEventInIndex(EventIn eventIn); 
SFTime getEventInTimeStamp(EventIn eventIn); 
void *getEventInValue(EventIn eventIn); 


typedef 


void *Node; 


void xgetNodeValue(Node *node, String fieldName); 
void postNodeEventIn(Node *node, String eventName, Field 


eventValue); 


/* 
* C script 


*/ 


typedef void *Script; 


Field getScriptEventOut(Script script, String eventName); 


Field getScriptField(Script script, String fieldName); 


void exception(String error); 


© 
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Browser Interface 


This section lists the functions that allow scripts to get and set 
browser information. For descriptions of the functions, see the 
“Browser Interface” section of the “Scripting” section of the spec. 
Since these functions aren't defined as part of a “Browser” class in 
C, most of their names include the word Browser for clarity. 


String 
float 


String 
void 


float 
void 


float 


float 
void 


boolean 
void 


String 
void 


float 


Node 
Node 


void 
void 
void 


void 
boolean 


getBrowserName( ) ; 
getBrowserVersion(); 


getBrowserNavigationType(); 
setBrowserNavigationType(String type); 


getBrowserNavigationSpeed( ); 
setBrowserNavigationSpeed(float speed); 


getBrowserCurrentSpeed( ); 


getBrowserNavigationScale(); 
setBrowserNavigationScale(float scale); 


getBrowserHead1light( ); 
setBrowserHeadlight(boolean onOff ); 


getBrowserWor1dURL(); 
loadBrowserWorld(String url); 


getBrowserCurrentFrameRate( ); 


createVrmlFromURL(String url); 
createVrmlFromString(String vrmlSyntax); 


addRoute(Node fromNode, String fromEventOut, 
Node toNode, String toEventIn); 
deleteRoute(Node fromNode, String fromEventoOut, 
Node toNode, String toEventIn); 


bindBrowserBackground(Node background); 
unbindBrowserBackground( ); 
isBrowserBackgroundBound(Node background) ; 
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void bindBrowserNavigationInfo(Node navigationInfo); 
void unbindBrowserNavigationInfo(); 
boolean isBrowserNavigationInfoBound(Node navigationInfo); 


void bindBrowserViewpoint(Node viewpoint); 


void unbindBrowserViewpoint( ); 
boolean isBrowserViewpointBound(Node viewpoint); 


System & Networking Libraries 


Example: 
/* 


* FooScript.c 


*/ 
#include "vrml.h" 


typedef struct { 
Script parent; 
SFInt32 fooField; 
SFFloat barOutEvent; 
} FooScriptType; 


typedef FooScriptType *FooScript; 
void constructFooScript(FooScript foo, Script p) { 
foo->parent = p; 
/* Initialize field(s) */ 
foo->fooField = (SFInt32) getScriptField(foo->parent, 
"Foo" y: 
/* Initialize eventOut field(s) */ 
foo->barOutEvent = (SFFloat) getScriptEventOut(foo- 
>parent, "bar"); 


} 


void processFooScriptEvents(FooScript foo, EventIn *list, int 
length) { 
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int i; 
for (i = 0; i < length; i++) { 
EventIn event = list[i]; 
switch (getEventInIndex(event)) { 
case 0: 
case 1: 
*foo->barOutEvent = *(SFFloat) foo->fooField; 
break; 
default: 
exception("Unknown eventIn"); 
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ambientColor, removal of 96 
ambient illumination 110. See also illumination; 
lighting 
ambient intensity, support for 148 
ambientIntensity field 110 
in Material node 147 
ambient sound 
creating 165 
description of by Sound node 162 
Anchor node _ 111 
angular distribution of light, controlling with 
cutOffAngle 167 


animation 65 

activation of by VisibilitySensor 181 

of children of Transform 177 

of cube, example of 174 

keyframed 110 

linear keyframed, and interpolator nodes 108 

and script nodes 35 

scripts 60 
ANSI C floating point format 184, 186 

in sftimeValue fields 191 

in sffloatValue fields 190 
API 

architecture 83 

browser functions supported by 62 

calls in Script nodes 116 

data types, in scripting language 62 

fields and 92 

Java bindings for 243 

Minimal 92 

script, in architecture 83 

scripting, datatypein 62 

synchronization 93 

VRML field types, exposure in 92 
appearance field, of Shape nodes 113 
Appearance node 74, 101, 102, 105 

advantages for implementation 75 

material field of 105 

texture field of, in MovieTexture node 149 
appearance properties, changes to in VRML 2.0 74 
Appearance Property nodes 74,75, 101, 102 
application protocols 25, 26 

e-mail 27 

HTTP/HTML 31 

and server programs 28 
applications, plug-in 33 
application-specific information 195 


250 Exploring Moving Worlds 


architectures 
all-API 83 
all-VRML_ 83 
areas, detection of by VisibilitySensor 181 
ARPA (Advanced Research Projects Agency) 27 
ARPANET 22, 27 
protocol 30 
ASCII characters 
interpretation as 170 
line termination by 42 
nonprintable 43 
ASCII code values 170 
associated events 46 
attenuation 
coefficients, in SpotLight node 167 
factor, in PointLight node 156 
audio. See sound 
AudioClip node 113, 114, 163 
audio, no, emission of in Sound node _ 163 
automatic behavior culling, by browsers 83 
avatars 196 
axis 
in billboard node 117 
rotation around 186 
axisOfRotation field 117,118 


B 


backdrop 116 
backface culling 106 
Background leaf node, behavior of 102 
Background node 103 

with Fog node 134 

hierarchies in 116 
background panorama 116 
Background stack 102 
backslash character, in SFString/MFString 186 
bandwidth-saving mechanism 76 
Basic Multilingual Plane (BMP) 170 
bboxCenter field, in Transform node 177 
bboxSize field 

in Inline node 142 

in Transform node 177 
beamWidth for inner cone angle 167 
beginCap field 131 
behavior 

activation of by VisibilitySensor 181 

Background leaf node 102 

bind stack 103 

creating/modifying 85 

culling 83, 86 

expressing the interface to 85 

field of Script node 60 

ideal, description of 105 

of objects 87 

of Viewpoint leaf nodes 102 


Bell, Gavin 6,10 
Berners-Lee, Tim 7 
bigRadius 81 
billboarding, special case of 118 
Billboard node 117,118 
bindable leaf nodes 179 
bindable nodes 103 
bindBackground() method 64 
bind eventIn 103 
in Viewpoint node 180 
binding nodes, and bind stack behavior 103 
binding, inC 243 
bindNavigationInfo() method 64 
Bind stack behavior 103 
bindTime eventOut, of Viewpoint nodes 180 
bind TRUE eventIn 103 
“black boxes” 85 
blanks 43 
Blau, Brian 10 
BMP (Basic Multilingual Plane) 170 
Boolean values, in fields 184 
Booleans, materialBinding /normalBinding 
specifications 97 
bounding boxes 
effects of VisibilitySensor on 181 
for animations in Transform 177 
in Collision nodes 120 
detecting visibility changes of 181 
of Inline node 142 
in Transform node 177 
and world creator, specification by 87 
bounding sphere, in Collision nodes 120 
Box node 119 
BoxProximitySensor node 53, 194 
animation of camera,in 214 
and avatars 196 
browsers 
automatic behavior culling by 83 
and C support 243 
communication with, proposal for 94 
and EXTERNPROTO instances 77 
interface 63-5, 240-41 
recognition of URL syntax by 180 
redrawing of scenes by 87 
rendering of refraction by 200 
and stacks, maintenance by 102 
sound channels, handling lack of sufficient in 163 
support of spatial localization of sound by 165 
support of URNsby 44 
support of user-interface mechanisms 51 
browser view, binding viewpoint to 179 
builtIn node 187 
built-in nodes 59 
implementation of, and URL syntax 81 
treatment of 79 
bundling properties 75 


Cc 
C 
binding in 243 
scriptsin 61 
source code, problems supporting 243 
Carey, Rikk 10 
carriage return character 42, 43 
Cartesian coordinate system 49 
case sensitivity 43 
cew field 105, 106 128 
center field 49 
center fields, in Transform node 178 
CERN 7 
CGI (Common Gateway Interface) 31, 32 
_changed 104 
_changed suffix 52 
characters. See also by name 
# 42 
backslash 186 
commas 183 
double quotes 186 
first 170 
ISO-10646 189 
line termination by ASCII 42 
innames 43 
sequence of 186 
square brackets 183 
children 45. See also leaf nodes; nodes 
adding/removing to rootnodes 89 
of Anchor grouping nodes 111 
of Billboard nodes 117 
of Collision nodes 119, 120 
description of 45 
exposing 92 
of grouping nodes 91, 107 
and Inline nodes 142 
and leafnodes 45 
number of, in Group nodes 137 
and pendulums 202 
setting ina Transform field 91 
and shuttles 202 
specifying events corresponding to 91 
of Transform nodes _ 80, 90, 177 
children field 91 
ChineseText node, defining acustom 202 
Chinese text, setting default directionin 202 
classes. See also by name 
exposed 233 
of nodes 45,73 
read/write 234 
ClickSensor node 53 
cloning. See multiple instancing 
codes 160 
ASCII 170 
collide field 120 
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collision detection 
default for 119 
in NavigationInfo node 150 
collision eventOut 120 
collision field, implementation of moment of 
intersection 120 
Collision grouping node 
and children, drawing of 119 
increasing efficiency in 120 
collision response 119 
collisions, namespace, avoiding 59 
color 117 
adding 98 
applying 105 
Diffuse, in PixelTexture nodes 154 
Diffuse, in texture map 138 
emissive, defaults for 105 
per-face 105 
per-object lighting 126 
PER_PART colors, adding 98 
per-vertex 105 
per-vertex materials/colors, proposal for 95 
RGB, in PixelTexture nodes 154 
RGB, in texture maps 138 
support of 148 
textures, precedence over 121 
in values fields 121 
writing to files 184 
color field 
in Fog nodes 134 
in IndexedFaceSet node 139 
in IndexedLineSet 143 
in PointSet node 156 
colorIndex field 140, 143, 144 
Color node 128 
colorPerVertex field 128, 140 
and color, adding, proposal for 98 
in IndexedLineSet node 144 
commas, in fields 183 
comments 42 
Common Gateway Interface (CGI) 31 
communication of location, support protocol 
for 195 
“compileVRML,” proposal for 94 
components, number of in image fields 184 
cone angle, inner, beamWidth, using for 167 
Cone node 123 
cones 123, 167 
consistency 197 
Const read-only class 233-234 
container objects 107. See also grouping nodes 
convex field 105, 106 
cookie-cutter extrusions 131 
coord field 122, 139 
CoordinateInterpolator 108, 109, 123 
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Coordinate node 105, 122 
coordinate systems 
for children of Transform 177 
local 105 
for scenes 49 
TouchSensor 176 
world 50 
coordinate transformations 72 
coordinates 
for keyframes 109 
number of in values field 123 
creaseAngle field 106 
createVrmlFromString() method 63 
crossSection 131 
cross sections, transformed 129 
cue events 163 
current time 
in audio field 115 
in Sound node 163 
cutOffAngle, and angular distribution of light, 
controlling 167 
cycleInterval 173 
and event generation in TimeSensors 172 
in TimeSensor loops 174 
Cylinder node 124 
cylinders 124 
CylinderSensor node 53 


D 


data storage, events for 86 
declarations 76,77. See also by name 
DEF 48,57 
defaults 
of crease angle 106 
direction, in Chinese text 202 
emissive color 105 
for prototype fields 77 
description field 
in AudioClip 114 
of Viewpoint node 180 
destroy routine 92 
diffuseColor field, in Material node 147 
diffuse color, in PixelTexture node 154 
diffuse objects, support of 149 
DirectionalLight node 126 
directOutputs field 89, 161 
“dirty” routes 87 
“dirty bits” along routes 86 
discrete field, and time/fraction events 173 
DiskSensor node 53 
distance, calculating in LOD node 144 
distributed naming 197 
distributed synchronization 197 


DNS (Domain Name System) 30 
double quotes 186 

drag sensors 176 

duration eventOut field 114 


E 
e-mail 27,28 
education, using 3Din 16 
electronic mail 27,28 
ElevationGrid node 
and creaseAngle field, use by 106 
modeling terrain with 127 
and SFBool fields 105 
ellipsoid, inner, in Sound nodes 164 
emissive color field 
defaults for 105 
in Material node 148 
emissive objects, support of 149 
emitter, location of, in Sound nodes 164 
enabled events, and TouchSensor 175 
encoding. See ISOs; UTFs 
endCap field 131 
enter time events, in ProximitySensor node 158 
environments, multi-user 60, 193-5 
errors 
in eventIn/eventOut declarations 58 
in Shape node 71 
European Particle Physics Laboratory (EPPL) 7 
eventIn events 52, 187,243 
bind 103 
bind, in Viewpoint node 180 
bind TRUE 103 
and data storage 86 
declarations 55 
and route establishment, proposal for 94 
set_fraction 108 
and state sharing 196 
eventOut events 52, 187, 243 
collision 120 
and data storage 86 
declarations 55 
isBound 103 
in MovieTexture node 149 
and route establishment, proposal for 94 
startTime_changed 114, 115, 173 
and state sharing 196 
touchTime, generation of 177 
events. See also by name 
associated 46 
data storage for 86 
enabled, and TouchSensor 175 
fraction 172-3 
generating 55 


generating, isActive, in TouchSensors 176 
generating, and Script node 160 


generating, in TimeSensors 51, 172, 173, 176 


generating, by user actions 53 
moving along aroute 86 
names 43 
orientation, in ProximitySensor node 158 
processing 60, 61 
queue of 61 
receive, contents of 93 
receiving of by nodes 52 
routing and state sharing 196 
send, contents of 93 
“time changed” 87 
time, and discrete fields, control by 173 
time, and TimeSensor nodes 172 
TRUE/FALSE and TouchSensors 176 
TRUE/FALSE in VisibilitySensor 181 
type, specifying 55 
eventsProcessed() method 61 
examine viewer, in NavigationInfo 150 
exception handlers 234 
Execution Model 61 
exposed classes and methods, for Java nodes/ 
fields 233 
exposedField keyword 46, 52, 53, 104 
enabling of 173 
in Script nodes 160 
exposed fields 86, 90 
and ROUTE statements 104 
in Script node 161 
ExtendedMaterial node 81 
extensibility 81-2 


extension mechanisms, and prototypes, replace- 


ment of 76 
extensions, registration of 60 
external files, defining prototypes in 58 
external prototypes 58 
EXTERNPROTO 48, 187. See also PROTO 
and alternative implementations 201 
animation in 209 
declarations for 77 
implementation of 78 
multiple URLs, specifying 81 
optimization of 90 
and prototypes, declaration 79 
in ROUTE statements 54 
and URLs _ 58, 77 
Extrusion node 
and creaseAngle field, use by 106 
objectsin 131 
and SFBool fields 105 
extrusions, cookie-cutter 131 


Index 253 


e 


faces 106 
FALSE events 
and TouchSensors 176 
in VisibilitySensor 181 
family field 135 
features, prototype 200 
Field class, functionality of 233 
field of view, default value of 179 
fields 45, 200. See also by name 
and API 92 
changing 64 
colorin 156, 184 
convex 105, 106 
discrete, and time/fraction events 173 
exporting 55 
exposed 86,90, 93, 104, 161 
family, description of 135 
geometry 105, 162 
get/set “exposed” 93 
greyscale in 184 
holding of VRML objects 55 
intensity, in Sound node 163 
loop, and TimeSensors 173 
multiple-valued 108, 183 
names 43 
innodes 46 
position, of Viewpoint node 179 
priority, inSound node 163 
in prototypes 78 
in scripts 160 
single-valued 108 
solid 105, 106 
source, in Sound node 163 
spatialize, and ambient sound 165 
square brackets 183 
string, contents of in Text node 169 
syntax for, list of 187-89 
types. See by name 
url 113, 160 
with URLs, VRML 2.0 43 
values, contents of 153, 159 
values, number of coordinates in 123 
values, number of normals in 152 
fields[] 76 
file extension, for VRML files 44 
file formats, syntax for 187 
file syntax vs. specification syntax 104 
first character 170 
flags 
directOutputs 89 
PerVertex 98 
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floating point values 116 
in SFVec2f/MFVec2f fields 186 
Fog node 133-34, 177 
font attributes 135 
fontStyle field 
and appearance nodes 102 
in Text nodes 134, 169 
FontStyle node 135 
and appearance property nodes 102 
description of 134 
in fontStyle field 169 
formats, movie, referral to by MovieTexture 
node 163 
fraction events 
and discrete fields, control by 173 
and TimeSensor nodes 172 
framerate 63 
frustum, viewing 181 
functions supported by browser API 62 


G 
Gelernter, David 229 
generating events 53,55. See also events; events by 
name 
geometric morphs 123 
geometric properties 
changes to in VRML 2.0 74 
and SFnode fields of geometry nodes 106 
geometric property nodes 107 
geometric sensor nodes 53, 74, 110 
geometry 
appearance of 105 
changes to in VRML 2.0 72,74 
of CylinderSensor node 125 
of Collision nodes 120 
re-use of in API architecture 84 
of SphereSensor node 167 
static, adding realism to 34 
syntax for 95 
of torus 81 
of TouchSensor node _ 176 
geometry field 105, 162 
geometry nodes 105 
and TextureCoordinate node 172 
and TextureTransform node, associated 171 
get/set “exposed” fields 93 
getClass() method 233 
getCurrentFrameRate() method 63 
getCurrentSpeed() method 63 
getName() method 62 
getValue() method 196, 234 
getVersion() method 62 
getWorldURL() method 63 
global information 62 


global nodes 107 
“glowing” objects 147 
Gopher 31 
grammar. See syntax 
graphical interfaces and world creation tasks 85 
gridStep field 127 
groundColors 116 
groundRanges field 116 
Group node 137 
grouping nodes 45, 72, 73, 107, 137-38. See also by 
name 
children of 47,91 
as prototypes, using 91 
grouping-node fields. See children 
groups, changes to in VRML2.0 72-73 
GUIs (Graphical User Interfaces) 85 


H 


hardcoding 200 
Hardenbergh, Jan 10 
headers, VRML file 43 
headlight field in NavigationInfo node 151 
height field 127 
hexadecimal values, representing image pixels 184 
hierarchies 
in background node 116 
manipulation of scenes 85 
scene 72 
scene graphs 47,50 
highlights, specular 147 
hitNormalevent 176 
hitPointevent 176 
hitTexCoord 176 
horizontal field 135 
horizontal text 136 
HTML (HyperText Markup Language) 31 
HTTP (HyperText Transfer Protocol) 31 


ideal behavior 105 
identification of user 195 
identifier utf8 for international characters 42 
See also UTFs 
illegal routes 52 
illumination. See also lighting 
ambient 110 
intensity of in Spotlight node 167 
of PointLight node 156 
images, in PixelTexture node 154 
ImageTexture node 138-39 
implementations 
built-in 81 
of prototypes 78-79 
run-time 75 


implicit set_ 104 
IndexedFaceSet node 72,105, 106, 121 
and attached Script 81 
and color, adding 98 
color fieldin 139 
description of 139-40 
inscenes 78 
IndexedLineSet node 105, 121 
and color, adding 98 
indexOfRefraction 200 
and hardcoding, understanding 200 
ignoring 200 
indirect illumination 110 
info field, and WorldInfo node 181 
information 195 
global 62 
storage of by WorldInfo node 181 
init routines 92 
inline implementation 58 
Inline node 142-43 
inner cone angle, beamWidth, using for 167 
inner ellipsoid, in Sound nodes 164 
instance variables 62 
instancing, description of 48 
instantiation 55,57 
intensity field, in Sound node 163 
Intensity-map 105 
interaction, with Moving Worlds 35 
interfaces 
browser 63-65, 240-41 
graphical, and world creation tasks 85 
public 104 
internal:name, as URLs, formof 81 


international characters, and utf8 identifier 42. See 


also UTFs 
Internet 7,9, 23-29 
ascommunity 9 
development of 7 
Netiquette 29 
protocols 23 
interpolator nodes 108 
IP (Internet Protocol) 23 
IP addresses 24 
isActive events 
and AudioClip 115 
generating, in TouchSensors 176 
generating of by TimeSensors 173 
in ProximitySensor node 158 
isA keyword 76,81 
and nodes, adding 200 
isAtRight, wiring output to Shuttle 206 
isBackgroundBound() method 64 
isBound eventOut event 103 
IS keyword 54,55 
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isNavigationInfoBound() method 64 
ISO 10646 standard 42, 43. See also UTFs 
ISO 10646-1:1993 136 

character 189 

character encodings 170-71 

and UTF-8 encoding 169 
ISO 639 = 136 
isOver 176 
IS syntax, for prototype implementation 79 
isViewpointBound() method 65 
isVisible, in VisibilitySensors 181 


J 


Java 
calls, libraries 241 
C bindings, for API 243 
description of 32, 233 
exposed classes and methods, for nodes/ 
fields 233-40 
interfaces, public, list of 240 
scriptsin 61 
syntax 62 
Java Object class, Field class and 233 
justify field 135 


K 


key values 108 

keyframed animation 110 
keyframes, coordinates for 109 
keys field 108 

keys, sort 163 

keywords. See by name 


L 


language attributes of text strings 136 
language constructs 196 
language field 136 
language mechanisms 61 
languages 
Chinese text 202 
HTML 31 
original VRML, limitations of 33 
Perl 61 
RFC 1766: language[_territory] 136 
scripting 61-62, 160 
use of any 85 
language tags, values for 136 
leaf nodes 45,74, 179. See also children; nodes 
leaves 74,198 
leftToRight field 135 
length field 169 
lexical analyzers 187 
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libraries 
creation of PROTO definitions 58 
Java 241 
networking 66 
object, creation of 225 
rendering, display lists for 90 
rendering, updates to 88 
system 66 
light. See also illumination 
angular distribution, controlling with 
cutOffAngle 167 
cone of, in SpotLight node 167 
illumination, specification of by attenuation 
coefficient 167 
in Material node 147 
nodes 177 
source 126, 167 
lighting. See also illumination 
calculating for optimization 139 
calculating, in PixelTexture node 154 
disabling 106 
OpenGL lighting model 148 
parameters, defined by Material node 147 
limited access, and Script nodes 89 
linear 
function 108 
interpolation 121,123 
keyframed animation 108 
line termination characters 42 
loadWorld() method 63 
local coordinate systems 105, 179 
local variables 62 
localization, spatial, support of sound, by brows- 
ers 165 
location 194-95 
LOD node 14446 
range fieldin 145 
sound nodes underneath, traversing 164 
logic 60 
loop field 
default for 114 
and TimeSensors 173 
TRUE/FALSE 114 
loops 
and event generation in TimeSensors 172 
in TimeSensor cycleInterval 174 
low-end rendering systems 148 


M 


Marbry, Jon 10 
material 
application of 105 
specifications in VRML 1.0 95 
materialBinding specifications, replacement by 
Booleans 97 


material fields, supported by low-end systems 
(table) 148 
Material node 102, 113, 200 
and color 121 
description of 147-49 
parameters, proposal for 96 
potential problems with 88 
Script nodes, sending events to 89 
as separate object 88 
specularColor fieldin 147 
MatrixTransform node, non-support of 73 
maxAngle 125, 127 
maxExtent field 169 
maxPosition, in PlaneSensor node 155 
mechanisms. See also by name 
bandwidth-saving 76 
browser support of user-interface 51 
convenience 76 
extensibility 81 
extension 76 
language 61 
object-definition 76 
optimization 76 
protection 76 


routing 88 
spatialization 165 
memory 


for nodes without routes 86 
Shape node, saving in 75 
methods. See also by name 
supported by browser API 62 
Meyer, Tom 10 
MFColor 184 
MFFloat 184 
in Text nodes 169 
MFInt32 185 
MFNode fields 87, 90, 92-93 185 
MFNode (new) 185 
MFRotation 186 
MFString 186 
MFTime (new) 186 
MFVec2f 186 
MFVec3f 123, 187 


MIDI 
controls 114 
files 113 


streams, number of 164 
MIME types 44, 113 
minAngle 125,127 
minBack 164. See also sound 
minFront 164. See also sound 
Minimal API 92 
minPosition in PlaneSensor node 155 
Mirror Worlds 228-30 
modeling transformations 49 


morphs, geometric 123 
mouse. See pointing devices 
movement. See animation 
movie formats, referral to by MovieTexture 
node 163 
MovieTexture node 
and movie formats, referral to 163 
and Sound node_ 163 
Moving Worlds 
description of 34 
examples of 217 
designing 217-32 
potential of 4, 16 
proposal, goals of 193 
proposal, strengths of 197-98 
specifications, changes between VRML 1.0 
and 198 
multiple references 48-49, 55, 57 
multiple threads, languages that allow 61 
multiple URLs 
and AudioClip 113 
in Inline node 142 
multiple-valued fields 108, 183 
multiple-value results 108 
multiply instanced nodes 49 
multi-user environments 60, 193-5 
multi-user interaction 60 
multi-user worlds 193-94 
mustEvaluate field in Script node 160 


N 
name scope, DEF/USE, description of 57 
namespace collisions, avoiding 59 
naming conventions 

events 43 

nodes 49 

package names 233 

prototypes 57,59 

UNIX file system 233 
naming, distributed 197 


naming specifications for UTF-8 encoding 43. See 


also ISOs; UTFs 
“native” implementation 81 
navigation, on the World Wide Web 7 
NavigationInfo stack 102-03 
Net News Transfer Protocol (NNTP) 30 
Netiquette 29. See also Internet 
network operations 60 


networking calls, Java libraries 241. See also Java; 


libraries 
networking libraries 66. See also libraries 
networks, receiving information over 195 
newline characters 42, 43 
newsgroups 29 
NNTP (Net News Transfer Protocol) 30 
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yg 


no audio, emission of in Sound node 163 
nodes. See also by name; objects 
accessing other, in scenes 62 
adding in VRML 1.0 200 
background, hierarchies in 116 
bindable 103 
built-in 59 
built-in, treatment of 79 
changes to in VRML 2.0 74 
characteristics of 45 
classes of 45 
collision grouping 119-20 
contents of 45 
event generation and 52 
events, sending/receiving 46 
extending set of existing 43 
fields in 46 
general 102-10, 188 
geometry 105, 171-72 
hierarchy, changes to structure of in 
VRML 2.0 70 
internal implementation of 59 
list of, alphabetical 111-181 
list of, by category 99-102, 188 
material, parameters, proposal for 96 
multiply instanced 49 


names 43, 49,54. See also naming conventions 


new Text, in Moving Worlds 202 
new, defining 200 
new, proposal for 95 
number of 43 
receiving events 52 
shared 194 
sound, as children of Transform 177 
specifications 104 
syntax 185, 188 
type, description of 54 
types, of prototype 78 
unnamed 49 
non-English text, rendering techniques for 134 
nonuniform scale, in TextureTransform node 
transformation 171 
normalBinding specifications, and Booleans, 
replacement by 97 
normal field, in IndexedFaceSet node 140 
Normallnterpolator node 108, 152 
Normal node _ 105, 151-52 
normals 
generation of by spheres 166 
number of in values field 152 
orientation of in Extrusion nodes 131 
notification process, for time changes 86 
now, changing 115 
NULL 186 
nxmarray 108 
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O 
Object class, Java, Field class and 233 
object libraries, creation of 225 
Object-Oriented Geometry Language (OOGL) 44 
objects. See also nodes 
behavior of 87 
bounding box for, in Transform 177 
container 107 
describing 45 
detection of by VisibilitySensor 181 
in extrusion nodes 131 
Material as separate 88 
occlusion of, sensing of by VisibilitySensor 181 
Web 230 
onCylinder FALSE/TRUE events 125 
onSphere 167 
oogl 44 
Open Inventor ASCII format 44 
OpenGL lighting model, support of 148. See also 
lighting 
optimization 
mechanism 76 
and rendering features 106 
ordered list of sound channels 163 
orientation event, in ProximitySensor node 158 
orientation field of Viewpoint node 179 
OrientationInterpolator node 153 
outValue event 108 
outValue events in NormalInterpolator node 152 


Pp 


package names, naming conventions for 233. See 
also naming conventions 

package vrml 233 

packets 24 

panoramas 116 

parent group of TouchSensor 175 

Parisi, Tony 10 

parsing 187 

PCM format 113 

pDAM 1-5, and UTF-8 encoding 169. See also 
UTFs 

Pendulum and isAtCCW/moveCwW, wiring 206 

pendulums 202 

per-face colors 105 

per-face materials/colors, proposal for 95 

Perl, scripts in 61. See also languages; scripts 

per-object lighting, support for by renderers 126 

PER_PART colors, adding 98 

persistent state of VRML objects 55 

per-vertex colors 105 

PerVertex flags, and texture coordinates, lack of 98 

per-vertex materials/colors, proposal for 95 


Pesce, Mark 9,10 
pitch 114. See also MIDI; sound 
pitch field 114 
pixels, components of in SFImage fields 184 
PixelTexture node 154-5 
planar cap surfaces 131 
PlaneSensor node 53 
plug-in applications 33 
pointing devices 
manipulation of in TouchSensor 176 
motion of, and CylinderSensor 125 
motion of, and SphereSensor 167 
and TouchSensor 175 
2D 175 
PointLight node 156 
PointSet node 105, 121 
and color, adding 98 
position events, in ProximitySensor node 158 
position field, of Viewpoint node 179 
PositionInterpolator node 157 
POSIX locale specification 136 
prefix set_ 52 
priority field, in Sound node 163 
priority values, forsounds 163 
processEvents() method 61 
processEvents routine 92,93 
properties, bundling 75 
PROTO 48, 187. See also EXTERNPROTO 
declarations for 77 
optimization of 90 
and prototype declaration 79 
in ROUTE statements 54 
and WWWaAnrchor, better 208 
PROTO keyword 54 
protocols. See also rules 
application 25 
application, and server programs 28 
ARPANET 30 
communication 195 
e-mail 28 
HTML 31 
WAL: Sh 
Internet 23 
NNTP 30 
prototypename 54,58 
prototypes 76-80 
declarations, changes toin VRML 2.0 76 
defined, number of 43 
defining in external files 58 
definitions inside prototype implementa- 
tion 57 
descriptions 54-7 
exporting fields 55 
external 58 


features 200 
fieldsin 78 
grouping nodes, using as 91 
implementation 54, 57, 58, 78-9 
and IndexedFaceSet, use inscene 78 
instantiation of 55,57 
interface, declaration of 77 
names 43 
naming conventions for 59 
node types 78 
and VRML 1.0 extension mechanisms, replace- 
ment of 76 
prototyping, description of 35 
ProximitySensor node 110, 158 
ProximitySensors 
in LOD node 145 
multiple 158 
proxy value of collide field 120 
public interface 104 
public Java interfaces, list of 240 


a 


queue of events 61 


R 


range field,in LOD node 145 
read/write class, for VRML field types 234 
realism, adding with Moving Worlds 34 
reality 5,228 
receive-and-display script 196 
receive events 93 
refraction, rendering of by browsers 200 
RefractiveMaterial node 200 
choosing sources, process of 202 
relative URLs 44 
remove_children event 91,178 
renderers 
per-object lighting, support for by 126 
and two cone model, support of by 167 
rendering 
features, optimizing 106 
libraries, display lists for 90 
low-end systems 148 
non-English text, techniques for 134 
optimization and features 106 
refraction, by browsers 200 
updates to 88 
rendering libraries. See also libraries 
display lists for 90 
updates to 88 
repeats field 139 
in PixelTexture node 155 
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repeatT field 139 

in PixelTexture node 155 
research, potential for with Moving Worlds 16 
RFC 1766: language[_territory] 136 
RGB colors 121 

in PixelTexture node 154 

in texturemaps 138 

writing to files 184 
robots 206 
root nodes, and children, adding/removing 89 
roots of scenes, and scripts, access toby 89 
rotation 

applying 129 

around axis 186 

clamping of in SphereSensor node 166 

events, clamping of 127 

feel of in SphereSensor node 166 
rotation fields 49 

in Transform node 178 
ROUTE statements 52,54, 79 

and exposed fields 104 

number of 43 
routes 85-8 

adding/deleting 64 

data copying in implementation/ optimization 

of 85 

description of 35,52 

“dirty” 86-87 

establishment, proposal for 94 

illegal 52 

memory for nodes without 86 

moving events along 86 

in multi-user worlds, adding 194 

from TimeSensor node 86 

and userData field, support of 196 
routines 92-93 
routing 

mechanisms 88 

structures, and behavior-culling 86 

syntax for 52 
rules. See also protocols 

of Internet 23. See also Internet 

and new node fields, description of 82 
run-time implementations, performance of 75 
Russel, Peter 232 


S 


ScalarInterpolator node 159 

scalar values 127 

scale field 49,178 

scale, nonuniform, in TextureTransform node 
transformation 171 

scaleOrientation field 49, 178 
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scene descriptions 63 
scene graph hierarchy 50 
scene graphs 
changes to 88 
contents of 47 
and run-time data structures 75 
SFNode pointers from 196 
and sound, location of in 164 
scene hierarchy 72, 85 
scenes 87 
accessing other nodes in 62 
contents of 49 
in IndexedFaceSet 78 
screen alignment 118 
Script declarations 54 
script, in API architecture 83 
Script node 107 
activation of 60 
animating with 35 
API calls 116 
behavior field of 60 
disposal of by browser 62 
and event generation 160 
interfaces 85 
and limited access 89 
and Material node, sending events to 89 
Minimal API 92 
in multi-user worlds 194 
operations performed by 93 
and prototype instancing 79 
and queue of events 61 
and ROUTE statements 104 
script nodes 
containing SFNode/MFNode fields 80 
description of 60 
scripting languages 61. See also languages 
API datatypein 62 
bindings for supported 160 
use of any 85 
scripts. See also by name 
and associated scenes, interaction with 243 
inC 61 
CGI 32 
creation of 160 
inJava 61 
keeping staticdatain 62 
language constructs, use of 196 
in Perl 61 
reading /writing to corresponding Script 
node 161 
receive-and-display 196 
and root of scene, access to 89 
and system/networking calls 66 


uses for 60 
and VRML browsers, communication with 161 
VRML nodes, access to 161 
scriptType field, in Script node 160 
searches, node, proposal for 94 
semantics, of Transform node 92. See also syntax 
sendevents 93 
Sensor node 53 
sensors, touch and drag 176 
Separator nodes, changes to in VRML 2.0 70 
server program 28 
setChildren 91 
setDiffuseColor event 86, 88 
set_fraction eventIn event 108 
set_prefix event 52 
set_startlime event 114, 115, 172 
set_stopTime “now” event 114, 115, 173 
setValue() method 234 
SFBool field 105, 184 
SFColor 121 
SFColor outValue event 184 
SFFloat 184 
class 62 
in Sound node 163 
values in ScalarInterpolator node 159 
sffloatValue 187 
SFImage field 184 
colors in, proposal for 96 
specifications for in PixelTexture node 154 
SFInt32 185 
sfInt32Value 187 
SFNode 185 
in multi-user worlds 195 
and pointers 196 
SFNode field 106 
SFRotation 186 
values, in OrientationInterpolator node 153 
SFString 186 
sfstringValue 187 
SFTime 186 
sftimeValue 187 
SFVec2f 186 
SFVec2f field 128 
SFVec3f 157, 187 
SGI (Silicon Graphics, Inc.) 11 
shadowing 88 
ShapeHints 72 
shape, in VRML 2.0 
Shape node 45, 113 
description of 162 
geometry field of 105 
memory, saving in 75 
in VRML2.0 71 


Shape objects 50 
shape properties, changes to in VRML 2.0 70 
shapes 
texture, changing on 171 
three-way decomposition of 71 
sharing 70-71, 194 
shutdown() method 62 
shuttles 202 
Shuttle, isAtRight, wiring output to 206 
Silicon Graphics, Inc. (SGI) 11 
single-valued fields 108, 183 
size field 
of FontStyle node, description of 135 
in ProximitySensor node 158 
size fields 134 
skyColor 134 
skyRanges field 116 
smallRadius 81 
solid field 105, 106 
sort keys 163 
sound 162, 164, 165, 175. See also audio; tempo 
channels 163 
data,in URLs 113 
as children of Transform 177 
limits to number of 114 
Sound node, source fieldin 163 
spacing field, description of 135 
spatialization mechanism 165 
spatialize field 165 
spatial localization, support of sound, by 
browsers 165 
specification syntax vs. file syntax 104 
specifying events, corresponding to children 
field 91 
specularColor field, in Material node 147 
specular highlights 147 
speed 
description of, in NavigationInfo 150 
of viewpoint 63 
Sphere node 166 
spheres 
in Collision nodes 120 
and normals, generation of 166 
SphereSensor node 166-67 
spine curve 130 
spine point, location of 130 
SpotLight node 167-68 
square brackets, in fields 183 
stacks. See also by name 
Background 102 
Bind , behavior of 103 
and browsers, maintenance by 102 
NavigationInfo 102 
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pushing Viewpoint to top of 179 
Viewpoint 103,179 
standard language mechanisms 61 
standard units of measurement 49 
startTime+cycleInterval 174 
loops 172 
startTime_changed eventOut 114-15, 173 
startlime event 173 
and AudioClip nodes, changes to 114 
changing 115 
and TimeSensor nodes 172 
startTime field 114 
in AudioClip 114 
inSound node 163 
state sharing, accomplishing by event routing 196 
staticdata 62 
Stephenson, Neal 5 
stopTime event 173 
changing 115 
stopTime field 114 
strings. See also by name 
field 169 
text 136, 169 
Unicode 238 
style field 135 
suffix_changed 52 
surfaces of revolution, in extrusions 130 
Switch node 168 
synchronization, API 93 
syntax 
of file formats 187 
file vs. specification 104 
for fields 187-89 
geometry 95 
ofIS 79 
Java 62 
keeping VRML1.0 91 
leaves 198 
MFNode field, example of valid 185 
node fields 185 
nodes 188 
nodetype {fields} 46 
public interface 104 
routing 52 
Transform nodes 90 
Transforms 198 
URL, recognition of by browsers 180 
URLs and built-in implementation 81 
Syntax Summary (BNF) 187 
system calls, Java libraries 241 
system libraries 66 
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tabs 43 
TCP (Transport Control Protocol) 
TCP/IP 30 

connections 25 

infrastructure of 7 
tempo 114. See also sound 
terrain, modeling with ElevationGrid node 127 
texCoord field 

in IndexedFaceSet node 140, 141 

2D coordinates in 172 
texCoordIndex field, in IndexedFaceSet node 141 
Text node 105 

description of 169-70 

and fontstyle fields 134 

new, in Moving Worlds 202 
text, non-English 134 
text strings, storage of in Text nodes 169 
texture 

application of 105 

and boxes, applying to 119 

andcolor 121 

and Cone node, application of to 123 

and cylinder, application to 124 

on shapes, changing 171 

of spheres, application of 166 

and 3D text, applying to 170 
TextureCoordinate node 105, 172 
texture coordinates 

defaults for 128 

and extrusions 131 

and PerVertex flags, lack of 98 

range of 172 

rules for 98 
texture field 113 


texture images, range of texture coordinates in 172 
texture map, as defined by ImageTexture node 138 


texture mapping, in PointSet node 156 
Texture node 102, 121, 169 
textureTransform field 171 
TextureTransform node 102, 171-72 
32-bit integers, in SFInt32/MFInt32 fields 185 
3D 
coordinate systems 4 
coordinates 122 
education, using in 16 
Internet programming, VAG standards for 10 
orientation parameters 129 
pointer device, coordinate systems for 175 
points, on hitPoint events 176 
shapes 139, 143 
text, applying texture to 170 
transformation, in Transform node 178 
vectors, in SFVec3f/MFVec3f fields 187 
Web, potential ofon 18 


world descriptions, MIME major type for 44 

worlds, viewing 34 
3D spine piecewise linear curve 129 
three-way decomposition of shapes 71 
time 

controlling passage of 51 

current, in Sound node_ 163 

value, in SFTime/MFTime fields 186 
time changes 

in AudioClip 115 

notification process 86 
time events 

and discrete fields, control by 173 

“time changed” 87 

and TimeSensor nodes 172, 174 
TimeSensor.cycleCount, initial value for 206 
TimeSensor node_ 110 

and AudioClip 115 

changes to 87 

control of 206 

and event generation 51,53, 174 

interruption of progress of 173 

restarting 114,173 

routes from 86 
topToBottom field 135 
Torus node 

geometry node 59 

geometry of 18 

internal implementation of 59 
TouchSensor node 

coordinate system of 176 

description of 175-77 

geometry of 176 
touchTime, in eventOut field 177 
trackPoint events 125 

in PlaneSensor node 155 
Transform node 

and avatars 196 

children of 80,90 

description of 177-79 

in ProximitySensor node 158 

semantics 92 

setting childrenina 91 

size of 177 

and transformations 48 

translation of, changing 79 
transformational hierarchy 107 
transformations 

accumulation of 50 

fields, of Transform node 49 

modeling 49 

nature of 170 

storage of 48 

in VRML1.0 72 
transformed cross sections 129 


translation field 49 
in Transform node 178 
transparency 147 
for ASCII code values 170 
values 148 
values in panoramas 116 
Transport Control Protocol (TCP) 24 
transporting 65 
traversed scene, and sound, hearing while part 
of 164 
TRUE events 
and TouchSensors 176 
in VisibilitySensor 181 
2D 
coordinates, in texCoord field 172 
crossSection piecewise linear curve 129 
scale parameters 129 
transformation 171 
2D devices. See also pointing devices 
display 49 
pointing 175 
two cone model, support of by renderers 167 
type field, in NavigationInfo 150 
typenames 45 
types, matching 52 


U 


UCS-2 (Universal Coded Character Set-2) 170 
UCS-4 (Universal Coded Character Set-4) 170 
UCS Transformation Format _ 170 
unbindBackground() method 64 
unnamed nodes 49 
Unicode Standard 2.0 170 
Unicode strings inJava 238 
UNIX file system, naming conventions 233 
UNIX to UNIX cp (UUCP) 28-29 
url field 113 
changing 114 
in Script node 160 
URLs (Uniform Resource Locators) 43-44 
and anchors 111 
creation of 7 
external prototypes, syntax for 59 
form of internal:name and 81 
in Inline node 142 
multiple 58, 81, 113, 142 
and referencing by EXTERNPROTO 77 
relative 44 
in Script node 160 
sound datain 113 
syntax of 81,180 
URNs (Universal Resource Names) 43-44 
in Script node 160 
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USE 48 
and multiple instancing 57 
and prototype implementation 78 
Usenet 29 
userData 196 
userDefined 187 
user-interface mechanisms, browser support of 51 
user interfaces 51 
users 
actions of and event generation 53 
current view of, manipulating 65 
identifying 195 
moving view of current 179 
representation of 196 
UTF-7 170 
UTF-8 (UCS Transformation Format) 170. See also 
ISOs 
characters 202 
characters, international 42 
in IdFirstChar 189 
and naming specifications 43 
string, in SFString/MFString fields 186 
in Text node 169 
utf8 identifier 42 
UTF-16 170 
UUCP (UNIX to UNIX cp) 28-29 


V 


VAG (VRML Architecture Group) 10, 11 
values 
coordinates, number of in values field 123 
field of view, default 179 
field 123, 152, 153, 159 
floating point 116 
hexadecimal, representing image pixels 184 
key 108 
language tags, values for 136 
MFVec3f 123 
panorama 116 
priority, forsounds 163 
proxy, of collide field 120 
retaining 62 
scalar 127 
ScalarInterpolator node 159 
SFNode, access to 185 
SFRotation, in OrientationInterpolator 
node 153 
time value, in SFTime/MFTime fields 186 
TimeSensor.cycleCount, initial 206 
transparency 116, 147, 148, 170 
whitespace between 186 
values field 
of ColorInterpolator 108 
colorsin 121 
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contents of in ScalarInterpolator node 159 
coordinates, number of in 123 
number of normals in 152 
values 108, 123 
variables, instance 62 
vertex locations 127 
vertical text 136 
vertices, order of 106 
verticesPerColumn field 127 
verticesPerRow field 127 
view 
changes to 87 
user’s current, manipulating 65 
user’s, moving 179 
viewing direction vector 134 
viewing frustum 181 
Viewing Model 50 
viewpoint 51 
binding to browser view 179 
changes to 179 
identifying in Viewpoint nodes 180 
placement of in VRML world 180 
speed of 63 
and stacks, pushing to top of 179 
Viewpoint leaf nodes, behavior of 102 
Viewpoint node 51, 102-03 
binding, 180 
stacks, pushing to top of 179 
Viewpoint stack 103, 179 
virtual reality, creating, challenges in 6 
Virtual Reality Modeling Language (VRML). See 
VRML (Virtual Reality Modeling Language) 
visibility changes of bounding box, detecting 181 
visibilityLimit field, in NavigationInfo node 151 
visibilityRange field 133 
VisibilitySensor node 110, 181 
VRML (Virtual Reality Modeling Language) 
API, Java bindings for 243 
browsers 33, 161 
C bindings for 243 
changing files, in API architecture 84 
complete programming language 84 
description of, 6, 45 
designers, intentions of 6 
features of, retaining 85 
field types, and API, exposure in 92 
fileextension for 44 
files, contents of 43 
files, indentification of 42 
future versions of 6 
implementation of images in PixelTexture 
node 154 
language, original, limitations of 33 
links 33 


MIME type for 44 

nodes, built-in, extending of by external 
prototypes 59 

origins of 9 

potential of 8,15 

scenes,soundin 162 

world, placement of viewpoint in 180 

VRML 1.0 

abilities of 6 

binding, proposal for 96 

comparison with 98 

and Moving Worlds specification, changes 
between 198 

scene, example of 198 

syntax, keeping 91 

vs. VRML 2.0 34 

VRML 2.0 

beginning of file characters for 42 

changes to structure of node hierarchy in 70 

scene, example of 199 

vs. VRML 1.0 34 
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WAIS (Wide Area Information Search) 30 
Web. See WWW (World Wide Web) 
whichChild field 168 
whitespace. See also characters 
between values 186 
characters 43 
preservation of 42 
as separator 186 
world coordinate system 50 
world creator bounding box, specification of 87 
WorldInfo node 42,107, 181 
.wrl 44 
in API architecture 83 
ROUTE statements 54 
WWWaAnrchor, description of 208 
WWWinhnline node 
changes to in VRML 2.0 74 
optimization of 90 
in VRML 1.0 83 
WWW (World Wide Web) 31 
development of at CERN 7 
navigation on the 7 
Web objects 230-31 
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x-vrml 44 
x-world 44 
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zones, in multi-user worlds 195 
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